Remove features
Opened this issue · 5 comments
A place to discuss feature removal in general, as per gkz/LiveScript#219
There are at least a few ways to approach this:
Ambiguity / Redundancy / Developer confusion
Features that--were coco mainstream--would appear in a "fractal of bad design"-type blog post. It's hard to be objective here, but some of my opinions are:
import
andimport all
vs.<<<
and<<<<
not function
: #189fn!?
andfn()?
Developer disuse / Compiler complexity
Features that require an inordinate amount of compiler complexity for their actual utility. To avoid subjective feelings about usage, it'd be cool to get metrics through some sort of AST walk--though some of the features only exist in the lexer, so adding a --stats
flag to the compiler would actually be kind of involved.
ES6 / Harmony compatibility
Features that either conflict with the new harmony proposals or have different syntax / semantics than the equivalent harmony version:
let
IEFE sugar vslet
block scoped variables- coffee-style string interpolation vs quasi-literals
- coco's
import
vs new module system's usage - current feature syntaxes that might look better for generator sugar, e.g. backcall vs.
yield
Going again through the additions's page, what I don't use. All these totally objective.
for ever
never used that, but it has its utility in several cases I can see
//$
regex string
unjoined interpolation
To add more after @qqueue :
inexistance
never used that and conflicts
number radix - confusing with number comments. ls changed that for ~
and I agree with it. I think it makes it usually harder to read most of the time anyway
import (all)?
AND <<<
. Maybe <<<
could have implicit @
as lhs ? Even more with implements
(I actually do use label
in several places, with setTimeout
import
vs<<<
Yeah, import
exists mostly historically (<<<
added later) and partly aesthetically (@<<<
is ugly). I guess we can remap it if more import
ant use cases arise.
not function
"but procedure." I kinda like this joke.
fn!? and fn()?
Bang-call came later and became surprisingly popular. Not really a loss since in this case you can't omit the parens when you have an argument:
f!
<->f a
f()?
<->f(a)?
ES6
I have a feeling that it might never get going at this rate, just like Perl6.
if more
import
ant use cases arise
Ha. Well, in the same vein as export
's quasi-commonjs sugar, import
could become another commonjs sugar similar to ls' require!
:
import <[ \utils/dom \utils/features ]>
# =>
[dom, features] = [require(\utils/dom), require(\utils/features)]
There should be a separate issue for "What to do with import
", if we're willing to kill it as an alias.
not function, but procedure
Cute, but I still don't like the !->
vs. !(it) ->
part. There's already an issue for that, though.
!?
... Not really a loss
I suppose so. I don't feel as strongly about it as I do about the others.
ES6
Even if it's a long way from completion as a whole, the proposals themselves have a lot of discussion under them as well as partial specs and implementation. Plus, the goal of "respect[ing] JS semantics and idioms" means we're going to have to choose between ES6 and coco legacy eventually.
important use cases arise.
I kinda like this joke.
Two jokes in one answer, ha!
ES6 and coco legacy eventually.
There are several points I don't agree with ES6 on, especially array comprehension and that are probably going to conflicts but before we can actually use them in prod (and I'm not talking about big companies making you support oldIE), let's hope things will have moved in some way. Which one is the question
import could become another commonjs sugar similar to ls' require!:
That seems too opaque for me. Not sure what to suggest here.
Features that require an inordinate amount of compiler complexity for their actual utility. To avoid subjective feelings about usage, it'd be cool to get metrics through some sort of AST walk--though some of the features only exist in the lexer, so adding a --stats flag to the compiler would actually be kind of involved.
using @satyr's old cokebench code, slightly modified https://gist.github.com/Nami-Doc/5165531
This was done to compare but still can be used to know if some features are especially slow. I wonder why coco's soak is 5 times slower.
Unjoined interp also seems useless to me (%"a#b c"
).
Object splat deserves to be better known.