Function Syntax

[Claus Reinke]

>>> ECMAScript has a large set of problems. .. 
>> - fixing ECMAScript's oddities would be worth a language 
>>    revision, even without adding anything new
> 
> This is a mistake. The Web does not permit "stop the world 
> and fix all known bugs". Neither users nor competing browser 
> or server-side software vendors will stop.

Ideals are like stars - out of reach, but good for orientation.

The fixes alone would be worth a revision, and a competitive
advantage (for language implementers and programmers,
though the both would be limited by code having to work
with other browsers). That ideal does not mean that language
changes should not be introduced incrementally (refactoring
beats rewriting). It only means that fixes can be as valuable
as new features.

> We do not all even agree on what the problems are. The 
> ones that we agree on, we are successfully working on 
> (modules, e.g.). Classes have had a rough time because 
> we don't even agree on premises or problems, never 
> mind conclusions or solutions.

Douglas will speak for himself, I'm sure, but my own 
interpretation of his remarks was that most current work
seems focused on extensions to the house, while there
are some concerns about the foundation (not limited to
functions). 

It wouldn't be too bad if some people work on the 
foundations and others on the extensions, but since the 
extensions are so much more immediately rewarding, 
it is easy to get carried away. In particular, one might 
worry about extensions introducing more problems 
and complexity, together with new features.

Removing unnecessary complexity will also make it
easier to add new features (fewer interactions to consider).

Another way to look at it: independent of the concrete
problems which you are working on, there seem to be
some meta-level problems that keep coming up and
get in the way of designing solutions. If that happens
often enough, it may be worth stepping back and solve
the meta-level problem first (no matter how horribly
difficult to handle that elephant looks;-).

> I'm working on better syntax, to present at the next TC39 
> meeting. I don't think "perfect" is an option in this life. I'm 
> aiming at "better".

Better is the road to perfect.

>> More concise function syntax is important, as long as the 
>> deeper issues get resolved, too.
> 
> What deeper issue beyond |this| binding (lexical, dynamic, soft, 
> etc.) do you mean, precisely?

I don't yet have a complete enough overview for detailed 
language criticism, but I've been posting my concerns here 
as I encountered them. 

It would be good to have a process for registering information 
and suggestions with the committee and get feedback about 
the official reactions to such suggestions (an es-discuss bug 
tracker perhaps, separate from the spec bug tracker?).

At this stage of my exploration, the main items seem to be:

- expressions vs statements
    this is well-known and would be hard to fix (too big a change 
    for javascript), beyond simplifying workarounds (such as 
    parameterless functions as block "values");

- grammar
    too many details are hard-coded here: that makes the language
    complex and inflexible for the language design process (syntax
    should not get in the way as often as it does here), and
    limits language expressiveness for programmers (especially 
    for abstraction providers); more of the changes that occupy
    TC39 should be possible at the level of libraries, not language;

- program equivalences
    what equivalences hold for js code? Language implementers,
    tool builders, and programmers depend on being able to 
    reason about code (optimizations, refactorings, code reading,
    maintenance, bug fixing);

    language-level equivalences are the most practical side of
    semantic tools: no need to reason about abstract machine
    details, or machine code, or mathematical constructs, just 
    "this high-level code fragment is equivalent to that one"/
    "we can replace this with that and nothing will go wrong"; 

    obviously, reflection breaks all equivalences (which is one 
    reason why mirrors and the like have been introduced: to 
    delimit the code affected by reflection); but even without
    reflection interference, it seems difficult to find valid code
    equivalences for javascript; 

    the more each instance of code has to be understood on 
    its own -rather than by relation/equivalence/simplification, 
    the more complex the language gets;

    it is great to have a detailed language spec (really! not all
    languages have one), but if we have to keep looking there, 
    to understand why obvious code equivalences fail in 
    javascript, the language becomes arcane (which is good 
    for consultant experts, bad for everyone else);

There are smaller items (some are instances of the above):

- objects vs blocks; grammar ambiguities;

- ASI coupling to combination of linebreak, error, restricted 
    productions serves neither full-ASI nor no-ASI proponents,
    and complicates language extensions;

- mixing numeric indices and string properties (every object
    is an array, only Array instances have proper array methods);
    dynamic typing is much less problematic without implicit
    conversions muddying the waters;

- var initializers shadow bindings in their rhs (similar to 'this'
    and 'arguments' shadowing, but worse through 'undefined');
    do we really need a different solution to each instance of
    shadowing problems? differences make for language
    complexity, extracting common solutions to common
    problems simplifies understanding;

- argument lists as arrays (instead of arrays as arguments)
    [this seems to be worked on];

- ephemeral nature of References; leads to syntactic junk in
    the language (syntactically valid code that predictably leads
    to runtime errors); also limits object methods as first-class
    values (they lose their base reference), breaks a dozen
    of "obvious" code equivalences (is this also behind direct
    vs indirect eval? I haven't checked yet);

- hardcoding of binary ops/precedences/associativity in 
    grammar; these are much too variable to be written in 
    stone, or be discussed by a language committee; for 
    javascript to be adapted quickly to new domains, these 
    should be in the hands of library authors and other 
    abstraction providers;

    much too valuable a tool to ignore; if combined with
    lightweight function definition and application syntax,
    it helps in defining readable domain-specific languages;

    commonalities in embedded domain-specific languages
    feed back into general purpose control abstractions, which
    again should be provided in libraries (moving more quickly
    than language committees);

Perhaps there were other items I don't recall right now (with 
a tracker, I could just look up my tickets, you could assign 
priorities, milestones, and committee members for those 
items you would want to adopt, and we'd all know where 
our suggestions stand).

> I'll keep it short by stopping here. Precision in stating 
> problems would be appreciated.

I hope this helps?
Claus