local

Brendan Eich brendan at mozilla.org
Thu Aug 21 06:31:32 PDT 2008


On Aug 21, 2008, at 6:12 AM, Michael Haufe wrote:

> Perhaps Brendan or someone else can shed light on the original  
> decision
> making process of "let"'s inclusion in JavaScript 1.7?


We added let to JS1.7 based on the ES4 proposal:

http://wiki.ecmascript.org/doku.php?id=proposals:block_expressions

The precedent for let is strong in many other languages, including  
Scheme and the ML family.

Keyword connotations aside, let has clear denotation in many  
programming languages. I don't think it's worthwhile for the list to  
bike-shed too much when many on the TC39 committee have recently  
expressed support for let declarations. More helpful would be  
comments on the utility of let blocks (a.k.a. let statements) and let  
expressions. Also comparisons to the several let forms in Scheme (Jon  
Z. posted something a while ago on this topic).

/be

> ---------------------------------------------------------------------- 
> --------------
>
> Ingvar von Schoultz wrote:
>> Steven Johnson wrote:
>>> If intuitively-plain English is a requirement, we'll have to  
>>> change some
>>> existing keywords... e.g., I submit that the meaning of "for" has
>>> little to
>>> do with typical English usage.
>>
>> You can read "for..." as and abbreviation of "for each value i
>> between 0 and 5, do this."
>>
>> Keywords don't have to be exact and complete. Given that the
>> "for" loop is useful and necessary, expressing it with "for"
>> is arguably the closest we can get.
>>
>> Our starting point must be the constructs that are useful and
>> efficient in programming. Given these constructs, we try to find
>> suitable words. This means that keywords will necessarily be
>> inexact and incomplete.
>>
>> The problem with "let" isn't inexactness or incompleteness, it's
>> that it's completely off the mark and unrelated, when read as
>> plain English. All other keywords are closely related to their
>> in-program semantics in some way.
>>
>> Regarding "for", a worse problem is this:
>>
>>     for (var key in map) {...}
>>
>>     for each (var value in map) {...}
>>
>> Both constructs expand into the same plain-English sentence. I
>> think this would be better:
>>
>>     for (var key in map) {...}
>>
>>     for (var value in values map) {...}
>>
>>     for (var [key, value] in [keys, values] map) {...}
>>
>
>
> _______________________________________________
> Es-discuss mailing list
> Es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss



More information about the Es-discuss mailing list