Function Syntax

Claus Reinke claus.reinke at talk21.com
Thu May 12 11:27:13 PDT 2011


Would it be possible for you to follow basic netiquette?

If you do not want to look for useful information in my
posts, there is no need for you to reply with unproductive
aggression. If you do want to reply to my posts, please
do so when you are calm and able to focus on making
productive contributions, preferably after spending more
than one second on reading and trying to understand
what you reply to, just as we do with your posts.

If you do want to restrict this list to certain topics, such
as discussing proposals made only by committee members,
you could simply state so on the list page. Clarification of
list aims and options for non-members to contribute to the
proposal process have been asked for here often enough.

Whatever it is you want - it is not acceptable that you leave
the burden of trying to keep discussions civil to others.

Claus

PS. I am tooling up to making more concrete suggestions,
    by reviving jsparse and moving its grammar to ES5. I have
    the technical background to implement my suggestions
    but, coming from another language community, I need
    to get a feeling for what is possible here, politically
    (preferably without the personal attacks).

    It was my understanding that the TC39 had internal
    communication channels for refining its proposals, and
    that this list was a public-facing add-on. Hence my talking
    about suggestions and directions before investing time
    implementing anything in detail.

    If this isn't the right list to talk about Javascript language
    design, please state so on the list page and clarify the
    community page entry for es-discuss.

    http://www.ecmascript.org/community.php

--------------------------------------------------
From: "Brendan Eich" <brendan at mozilla.com>
Sent: Thursday, May 12, 2011 7:06 PM
To: "Claus Reinke" <claus.reinke at talk21.com>
Cc: "Douglas Crockford" <douglas at crockford.com>; <es-discuss at mozilla.org>
Subject: Re: Function Syntax

> On May 12, 2011, at 7:42 AM, Claus Reinke wrote:
>
>>>>> 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.
>
> Bodies were heaped by the millions over the last few centuries in the name 
> of ideals. I detest _a priori_ systems that ignore empircal results. I 
> don't buy "ideal" without "real". Your message is woefully lacking in 
> "real".
>
>
>> 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.
>
> This is all vague sermonizing. Please stop.
>
> There's a dream syntax Doug can glimpse (maybe I can too; working on it 
> still) that might be called a "fix". It relieves us of semicolons and ASI 
> without creating runtime migration traps.
>
> Ok, show it. Or show a way to find it, a concrete method. The endless 
> ideal-mongering and vagueness don't cut it, and they are actually adding 
> noise and making trouble.
>
> If we keep this up, we will have neither fixes (including the ones *in 
> hand*, e.g. lexical scoping) nor new features in ES.next.
>
>
>>> 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).
>
> Vague words, and where testable,  precisely wrong. Lexical scope all the 
> way up, modules, let, const, some of the object initialiser extensions, 
> and (I argue) paren-free and the for-in reform it enables -- these are all 
> fixes.
>
>
>> 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;-).
>
> For me to keep parlaying here, you need to be specific or else stop 
> injecting so many generalizations which are either useless, or actually 
> false when applied to specifics I've listed above.
>
>
>>> 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.
>
> No, there is no perfect. Get this right, or you are in dreamland (and I am 
> elsewhere).
>
>
>>>> 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");
>
> Ok, so you say this is not realistically solvable. Why bring it up?
>
> Next:
>
>
>> - 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;
>
> You're arguing we can't improve the syntax of the language, even by 
> extension? False: let, const (already in browsers in a form that can be 
> fixed), lexical scope to get the global object off of the scope chain 
> (this is an important security fix), and modules.
>
> Also: libraries are many and evolving, TC39 design-by-committee is about 
> the worst way to invent and evolve a library. We're de-facto standardizing 
> (ES5 did the Array extras, which still have some flaws we cannot fix).
>
>
>> - 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;
>
> (It's not that bad in practice once you [the refactoring entity] buy into 
> having to lex and parse everything. This seems a formal objection.)
>
>
>>   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);
>
> This is long-winded and vague still (also badly formatted). What is your 
> specific, actionable point?
>
> We can't lose statements with control effects without a big compatibility 
> break, and you ruled out new syntax above. Are you arguing against 
> changing JS, and for inventing a wholly new language?
>
> Just yesterday I re-raised the {|a,b| a+b} Ruby/Smalltalk-inspired 
> block-as-lambda idea recently. It has the advantage of being concrete. It 
> preserves certain program equivalences at the price of creating new 
> runtime error conditions (return from an outer function call that has 
> already returned, e.g.). Please address it specifically, or make a 
> competitive alternative proposal.
>
>
>> There are smaller items (some are instances of the above):
>>
>> - objects vs blocks; grammar ambiguities;
>
> This is a glitch JS hackers I've surveyed informally simply learn and get 
> past. They don't even complain about it much, compared to lack-of-ASI 
> (lack of significant newline) traps. I've talked to many over the years.
>
> Anyway, it is not going to be fixed without a new grammar, which you seem 
> to have ruled out above.
>
>
>> - ASI coupling to combination of linebreak, error, restricted 
>> productions serves neither full-ASI nor no-ASI proponents,
>>   and complicates language extensions;
>
> Yes, this is true and we've had proposals, including Mark's concrete 
> proposal for a better ASI and Harmony parsing both ways, declaring an 
> early error on disagreement. Unfortunately this requires backtracking and 
> error recovery in a "forked parser", so it looks too complicated for 
> implementors *and* users, but it was a concrete proposal in the right 
> direction. Please do likewise and stop rehashing the problem statement.
>
> http://www.mail-archive.com/es-discuss@mozilla.org/msg05606.html
>
>
>> - 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;
>
> I proposed tuples. They got a mixed reaction at the last tc39 meeting, and 
> they are not likely to get into ES.next at this point. Do you have 
> anything to add to this specific proposal, or another alternative specific 
> proposal to make?
>
> http://wiki.ecmascript.org/doku.php?id=strawman:tuples
>
>
>> - 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;
>
> This is a topic for let and const in blocks, which is still being debated 
> on-and-off. IIRC most of TC39 agreed to make let and const start a new 
> implicit scope, so an outer name could be used in the initialiser.
>
> Again, we can't change var unless you want us to make incompatible 
> changes, which you seemed to advise against above. Which is it?
>
>
>> - argument lists as arrays (instead of arrays as arguments)
>>   [this seems to be worked on];
>
> It *is* being worked on, you should know that -- rest and spread are in 
> harmony -- yet you rehash and inject noise again here. Why? To channel 
> Nancy Kerrigan: WHYYYYY???? :-|
>
> http://wiki.ecmascript.org/doku.php?id=harmony:rest_parameters
> http://wiki.ecmascript.org/doku.php?id=harmony:spread
>
>
>> - 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);
>
> This is not only a minor issue, truly small potatoes -- it is required for 
> web compatibility due to VBScript-tainted JScript of this kind:
>
> d.items(i) = j;
>
> That kind of crap exists in IE-only branches of JS on the web, so it must 
> parse.
>
> Let's focus on real problems affecting real users.
>
>
>> - 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);
>
> Sorry, we're not turning JS into Haskell or making the syntax, 
> particularly the operators, have adjustable precedence and associativity. 
> This is not something developers or implementors want. It has never been 
> on the agenda, even for value types/proxies. You are barking up the wrong 
> tree here.
>
>
>> 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?
>
> Not really.
>
> I'm being rough on you here because we have a serious (serous enough, for 
> a discussion list I care about not going in ideal-mongering circles or 
> filling with useless noise and posturing) problem. We have real proposals 
> for ES.next on the table. They aren't all necessarily going to make it, 
> but trying to reset the discussion from them to vague ideals or non-issues 
> like programmable operator precedence does a disservice to our common 
> effort here.
>
> We need to get back to discussing the live strawman proposals, and 
> refining the proposals in harmony but not quite spec'ed fully. Will you 
> help?
>
> /be

 



More information about the es-discuss mailing list