Spawn proposal strawman

[Brendan Eich]

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