On Wed, Oct 12, 2011 at 5:08 PM, Brendan Eich <bren...@mozilla.com> wrote:
> On Oct 7, 2011, at 6:51 AM, Mikeal Rogers wrote:
>
> On Thu, Oct 6, 2011 at 5:08 AM, Brendan Eich <bren...@mozilla.com> wrote:
>
>> On Oct 4, 2011, at 10:52 AM, Mikeal Rogers wrote:
>>
>> > But, some of them simply double the semantics and syntax in the language
>> without a path to deprecate previous syntax. I'm a big fan of let, but if
>> you don't deprecate var we're going to have to contend with new programmers
>> keeping two sets of scoping rules in their head.
>>
>> You mean by deprecate what, exactly?
>>
>> Web JS is full of var. Making any attempt to migrate a big hunk of it to
>> ES6 require replacing all 'var' with 'let' is a huge tax, since scoping
>> works differently.
>>
>> Ok, how about saying if you use 'let' in a function or at top level, you
>> can no longer use 'var'? That's less of a tax on average, but for a long
>> program or single function, it's as bad.
>>
>
> This is exactly what I was getting at.
>
>
> Andreas Rossberg brought it up. We can put it on the agenda for the
> November meeting, but it could be better to discuss here first, if people
> have specific migration stories involving let and var (say, from Firefox
> add-on or browser JS).
>
>
> My main point was that syntax is hard. But syntax is UI and JS's UI has
>> real usability bugs. I'm glad you find it easy to teach. That's not the only
>> consideration though, because after people learn a language, as they keep
>> using it they do progress to become fluent, even expert, at it, and its
>> usability problems come to the fore.
>>
>
> Semantics for experts is fine so long as the syntax doesn't confuse
> beginning to intermediate programmers. Like I said, I think the
> destructuring proposal is a great example of syntax that makes the semantics
> behind it obvious especially when compared to what it takes to accomplish
> the same task now.
>
> I would contrast that with generators. With ES5's forEach, map and filter,
> which are quite simple and obvious,
>
>
> The meanings of the optional parameters are not super-obvious, but ok.
>
>
> I wonder why the semantics of generators can't be achieved in a way that is
> clearer to less than expert programmers.
>
>
> What's the problem? You didn't say.
>
> The semantics of generators must be such that the compiler can tell when a
> function is a generator. So something is going to signify "this function is
> a generator".
>
> (We already went around the block with using "generator" as a keyword --
> that's not a reserved future word so it would need to be reserved as a
> breaking change, or possibly only if it comes after a line terminator, but
> then anonymous generators are still incompatible. I.e., you could have JS
> today of this form:
>
> x =
> generator
> (a, b)
> {
> }
>
> which if generator names a callable object and a and b are bound, is
> perfectly legal.)
>
You have to admit, this is *highly* unlikely. I know there are uses for
yield-less generators (at least, so I've been told -- can you remind me of
the specific cases?), but if code has to be contorted into the shape of the
above example for it to be ambiguous I'm not inclined to be terribly
sympathetic to the rare sucker that falls into this trap during conversion.
I could also see this as causing problems for someone authoring in harmony
code and using `generator` as the name for a method shorthand. But meh, if
they know method shorthand they should know that generator's newly reserved.
But this reminds me -- has anyone proposed a method shorthand for
generators? Is it worth it? If so, it occurs to me that moving the * to
after the head for both function and method generators could be one way to
unify the two:
function()* { yield ... }
var x = {
foo()* { yield ... }
}
ISTR a comment Brendan made about the current function* syntax keeping the
grammar simple -- I'm not sure how that would apply to the above suggestion.
[snipped the rest]
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
