function hoisting like var

[Ingvar von Schoultz]

Igor Bukanov wrote:
> 2008/7/28 Ingvar von Schoultz <ingvar-v-s at comhem.se>:
>> If [...] is preceded by =, or enclosed in ( ), or in some other
>> position where you can't have a block, it's a literal. If it's
>> a literal it must contain a comma-separated list of values, so
>> if the syntax doesn't match this, it's a block.
> 
> Such rules require an arbitrary look ahead in the parser so it can
> distinguish that in cases like
> 
>   if (x) [arbitrary_expression;]
> 
> [] means a block while in
> 
>   if (x) [arbitrarily_expression];
> 
> [] would mean a literal.
> 
> This would require a mayor change in most if not all current ES parser
> implementations. There were some proposals for ES4 syntax that would
> require such look ahead, but they were rejected not only technical
> grounds but also on the grounds that such look ahead poses
> comprehension problem for a human brain! And here are we talking about
> a minimalistic sugar for ES3.1.
> 
> Regards, Igor
> _______________________________________________
> Es3.x-discuss mailing list
> Es3.x-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es3.x-discuss
> 

I wasn't aware that backtracking was a difficulty. That makes
quite a difference!

In theory this could be overcome. Often the ambiguity doesn't matter:

     if (x) [a(), b(), c()];

Block or throwaway array, the end result is the same. So in principle
you could start out building an array, and on the first nonmatching
syntax you discard the half-built array and build a scope block
instead:

     if (x) [a(), b(), c(), d(), e(), let f = g;]

Of course in practice such a solution is too messy, unless you have
some extremely thorny problem that just can't be solved in any other
way. And this certainly isn't that kind of problem. So [ ] are out.

Unless they're reincarnated as:

     [: code :]

Ah, now I know! I have the perfect solution, guaranteed to be
unambiguous. Happy code!

     (-: Scoping blocks are delimited by smileys! :-)

-- 
Ingvar von Schoultz

------- (My quirky use of capitals in code comes from my opinion that
reserved and predefined words should all start with lowercase, and
user-defined should all start with uppercase, because this will easily
and elegantly prevent a host of name-collision problems when things
like programming languages are upgraded with new labels.)