On Apr 18, 2011, at 1:45 AM, Claus Reinke wrote:
>> The bigger problem is not the rule-space but the mixed significance and
>> insignificance of line terminators.
> ..
>> .. The line terminator having selective meaning due to ASI as an error
>> correction procedure, and of course in restricted productions, creates an
>> expectation that line terminators matter in general.
>> However, going down that road leads to CoffeeScript, or (somewhat more
>> conservatively due to the use of : at end of head forms, and a lot older)
>> Python. It's a steep slippery slope.
>
> I was trying to point out that CoffeeScript, Python, Ruby, ..
> all have subtly different systems, which in turn differ from
> Haskell's system, and others in that space.
No, your original post mentioned none of CoffeeScript, Python, or Ruby. You
mentioned only Haskell.
> It is not useful to throw them into a single pigeon hole.
I certainly did not throw Haskell into a single pigeonhole with CoffeeScript or
Python. And my reply does not contain the word "Ruby" at all!
I do group CoffeeScript and Python together, while acknowledging their
differences (please, no pedantic nit-picking on this point). They both have in
common indentation-based block (or similar control or body) structure, with
significant newlines.
> The remainder
> or your reply shows that you are aware of that, so I am
> surprised that you start with this misleading statement!-)
What was misleading?
You injected Ruby and implied I put Haskell in the same category as
CoffeeScript, Python and Ruby, cited above. It seems to me the shoe is on the
other foot. Grump!
> However, it would be useful to have a Javascript implementation
> of a Javascript parser and unparser (precisely reproducing the
> source). Then one could prototype such syntax modifications
> as source-to-source translators, perhaps even testing whether a rewrite
> changes parse-followed-by-unparse results.
> There are lots of parsers, and some pretty-printers, but I'd like it to be in
> Javascript (rather than in Haskell;-), so that some of you are likely to use
> it, and it needs to work for me on Windows.
> Or would you be happy if I used one of the Haskell libs for JS?-)
Narcissus is actively developed, Tachyon is another metacircular VM (we are
joining forces between these two), there are more than a few others out there.
But they all lack the bottom-up grammar validation (modulo classic-ASI) that we
need to be sure we're not just having fun hacking, with insufficient tests.
>>> And blog posts seem to be more about trouble with ASI than about usefulness
>>> of ASI [2,4,5].
>> Beware negativity and confirmation biases here.
>
> If did my references correctly, those posts were explanatory,
> in the direction: "you cannot avoid ASI, so you better understand
> how it works".
That's fine, but this "you better understand [ASI]" conclusion is a change from
what you wrote previously. Your entire paragraph was:
"It is interesting that even the ES5 spec has no convincing
ASI examples, only clarifying examples (7.9.2). And blog
posts seem to be more about trouble with ASI than about
usefulness of ASI [2,4,5]. So ASI as it stands in Javascript
now does not only make life harder for programmers but
for spec writers (and readers), too."
and I replied objecting to the conclusion from negatively biased blog posts
that ASI makes life harder. It also makes life easier but there are no blog
posts to cite.
>> ASI is relied on by tons of content, without complaints (or praise). It goes
>> without notice when it works, which is often when a ; was left off where the
>> formal grammar requires it.
>
> Very likely. Coders may not even be aware when they rely on ASI.
My point, which seems to override your "ASI as it stands ... [makes] life
harder for programmers [and] spec writers".
ASI makes some things easier (reduces costs of constructing JS programs
quickly, or in a preferred ;-free style) and it makes other things harder. We
can agree on this at least.
Is ASI a net loss across history and all developers? I doubt it, but it would
be great to improve -- I have no doubt that it is not the "last, best" solution
of its kind.
Still, ASI will be hard to get rid of, and a new system would need to
interoperate within the spec and implementations, and in developers' minds.
> I wasn't referring to the ASI spec. When browsing the list
> archives, I noticed that discussions of syntax tend to drift into parser
> issues, and sometimes, when contributors have almost settled on a suggestion,
> out of nowhere comes an ASI issue ("if we split this over two lines, it is
> going to be ambiguous").
Yes, that's true.
> Or simple operator proposals such as modulo operators have to consider
> restricted productions.
Indeed, although it's questionable how many identifier-named infix operators we
want to add.
> My impression was that ASI concerns are hampering
> language development, because ASI doesn't operate
> separately - it is entwined with the grammar.
Language history always hampers development. ASI will die hard. I'm not sure
more generalizing will help us get to "the next thing".
>> What we could use is some validated alternative that has no runtime
>> migration error gotchas.
>
> But even if the alternative has a nice specification, how to
> validate that it doesn't ruin people's coding patterns without
> knowing what those coding patterns are?
Using formal methods on the grammar including restricted productions, and ASI
as an error correction algorithm.
In the end, TC39 (I'm thinking of Waldemar) will require that anyway.
> I was thinking about *non-standard* increments
Ok, I agree that could work although convincing implementors to add pragmas,
then convincing developers to use them, is hard. And without a formal approach
we won't get to standardization, so I'd start with formal methods first.
> Yes. My suggestion was to take the assumptions out of the game - no
> complicated analysis, just indentation. But one would have to deprecate
> first, have tools warn developers
> if they use coding patterns that are going to break, then offer transition
> help. A longish process..
And here, I think standardization would be required to get the bandwagon
effects.
>> But since you wrote a nice post and seem motivated, I do want to encourage
>> you to work out more details.
>
> Thanks for the useful explanations. It might be worth having
> them on the wiki, as an ASI-non-proposal with rationale.
I'm a bit grumpy about the earlier pigeonhole accusations and Ruby injection,
but let us hope we can get past that.
Really, though, the wiki doesn't need more mooting and what-ifs and "how
Haskell does it" summaries. Let's try to formalize here, at least a bit, if we
can. Otherwise we aren't going to get far.
/be
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
