Remove features

Question

Remove features

Opened this issue 11 years ago · 5 comments

A place to discuss feature removal in general, as per gkz/LiveScript#219

Answer 1 · 2013-03-11T20:23:18.000Z

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 and import all vs. <<< and <<<<
not function: #189
fn!? and fn()?

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 vs let 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

Answer 2 · 2013-03-11T20:50:27.000Z

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

Answer 3 · 2013-03-11T22:29:14.000Z

import vs <<<

Yeah, import exists mostly historically (<<< added later) and partly aesthetically (@<<< is ugly). I guess we can remap it if more important 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.

Answer 4 · 2013-03-12T01:08:40.000Z

if more important 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.

Answer 5 · 2013-03-14T21:46:38.000Z

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.