Spawn proposal strawman

On May 9, 2009, at 2:59 PM, Mark S. Miller wrote:
> On Sat, May 9, 2009 at 2:32 PM, David-Sarah Hopwood
> <david-sarah at jacaranda.org> wrote:
>> [...] but the AST should preserve the associativity defined in the
>> language spec.
>> But which language spec? Again, specs only traffic in observable
> differences. Since ES5 does not define any std parse or AST API, there
> is no observable difference in ES5 whether this is specified as
> left-or-right associative.
Exactly.
> Assuming ES6 does define such APIs, the
> difference becomes observable. I see no reason why ES6 could not
> compatibly specify a right associative grammar for || and &&.
Glad to hear this. I'm going with right associativity for local-
convention and lazy-hacker reasons, in the SpiderMonkey prototype.
Of course if we standardize left-associative || and &&, I will cope --
software can do anything. But there's a slight and (IMHO) winning
economy of expression, interpretation, and compilation, in right
associativity for these logical connectives.
Ritchie's original C compiler, and Thompson's implementations of B
(initially for a very limited memory machine, PDP-7), focused on one-
pass code generation. This obviously made for busy-work burdens
(forward declarations, e.g.) for the C programmer. At first (B on the
PDP-7) there was no alternative. BCPL had a "let rec" equivalent ("let
X be ... and Y be ...") but Thompson's target machine had insufficient
core to hold an intermediate representation in memory for real
programs. I'm pretty sure all these compilers treated & and | (which
split into && and || later, explaining the poor precedence for & and
|) as right-associative.
Today we have too much memory to waste, and hardly any living
programmer worries about such things as fitting a compiler in 8K.
More's the pity.
But why shouldn't we bias the AST, in this particular case, toward the
more economical associativity mode?
/be