On May 11, 2011, at 4:23 PM, Mark S. Miller wrote:
> On Wed, May 11, 2011 at 2:15 PM, Brendan Eich wrote:
> See http://wiki.ecmascript.org/doku.php?id=harmony:egal -- I took the liberty
> of renaming 'eq' to 'is' and I made the operator idea from the November TC39
> meeting concrete.
>
> Note
On Wed, May 11, 2011 at 2:15 PM, Brendan Eich wrote:
> See http://wiki.ecmascript.org/doku.php?id=harmony:egal -- I took the
> liberty of renaming 'eq' to 'is' and I made the operator idea from the
> November TC39 meeting concrete.
>
> Note that egal as an ''is' operator, with 'isnt' as the not-e
On May 11, 2011, at 9:53 AM, Brendan Eich wrote:
> ...
>
> 3. Blocks as implicitly quoted code could be like zero-argument lambdas, with
> break, continue, return, |this|, and |arguments| referred to any outer
> function or loop/switch statement. This suggests something like the Ruby-ish
> sy
On May 11, 2011, at 7:40 AM, Garrett Smith wrote:
> On 5/10/11, Allen Wirfs-Brock wrote:
>>
>>
>> At a meeting today, the dichotomy we used in talking about this is the
>> difference between "imperative programmers" and "abstraction builders".
>> Imperative programmer know how to use basic imp
See http://wiki.ecmascript.org/doku.php?id=harmony:egal -- I took the liberty
of renaming 'eq' to 'is' and I made the operator idea from the November TC39
meeting concrete.
Note that egal as an ''is' operator, with 'isnt' as the not-egal operator,
differs from CoffeeScript's 'is' and 'isn't, wh
On May 11, 2011, at 11:51 AM, Mark S. Miller wrote:
>
>
> On Wed, May 11, 2011 at 11:41 AM, felix wrote:
> I think he's proposing that the 'eval' function would be a magical
> function that can inspect its calling environment to determine whether
> it's being called in a lexically strict conte
False alarm. I have finally (just) received the e-mail.
David
Le 11/05/2011 21:44, Oliver Hunt a écrit :
> On May 11, 2011, at 12:38 PM, David Bruant wrote:
>
>> Le 11/05/2011 20:38, felix a écrit :
>>> On Wed, May 11, 2011 at 11:16, David Bruant wrote:
A memoizer could be written to improv
On May 11, 2011, at 1:04 PM, Oliver Hunt wrote:
> On May 11, 2011, at 12:54 PM, Brendan Eich wrote:
>
>> On May 11, 2011, at 12:44 PM, Oliver Hunt wrote:
>>
>>> So you want to do
>>> if (map.has(bar))
>>> wiffle = map.get(bar)
>>>
>>> or some such?
>>>
>>> The problem here is that you can't gu
Le 11/05/2011 21:54, Brendan Eich a écrit :
> On May 11, 2011, at 12:44 PM, Oliver Hunt wrote:
>
>> So you want to do
>> if (map.has(bar))
>> wiffle = map.get(bar)
>>
>> or some such?
>>
>> The problem here is that you can't guarantee that GC won't happen between
>> those two calls, and therefor
On May 11, 2011, at 12:54 PM, Brendan Eich wrote:
> On May 11, 2011, at 12:44 PM, Oliver Hunt wrote:
>
>> So you want to do
>> if (map.has(bar))
>> wiffle = map.get(bar)
>>
>> or some such?
>>
>> The problem here is that you can't guarantee that GC won't happen between
>> those two calls, an
On May 11, 2011, at 12:44 PM, Oliver Hunt wrote:
> So you want to do
> if (map.has(bar))
> wiffle = map.get(bar)
>
> or some such?
>
> The problem here is that you can't guarantee that GC won't happen between
> those two calls, and therefore you could still end up getting undefined in
> resp
On May 11, 2011, at 12:38 PM, David Bruant wrote:
> Le 11/05/2011 20:38, felix a écrit :
>> On Wed, May 11, 2011 at 11:16, David Bruant wrote:
>>> A memoizer could be written to improve f time performance (by the cost of
>>> memory, of course).
>>>
>>> function memoizer(f){
>>> var cache =
Le 11/05/2011 20:38, felix a écrit :
> On Wed, May 11, 2011 at 11:16, David Bruant wrote:
>> A memoizer could be written to improve f time performance (by the cost of
>> memory, of course).
>>
>> function memoizer(f){
>> var cache = WeakMap();
>> return function(o){
>> var res;
>>
On Wed, May 11, 2011 at 11:41 AM, felix wrote:
> I think he's proposing that the 'eval' function would be a magical
> function that can inspect its calling environment to determine whether
> it's being called in a lexically strict context or not, and based on
> that it would act like the strict e
On Wed, May 11, 2011 at 11:16 AM, David Bruant wrote:
> Hi,
>
> I've recently been thinking about the case of memoizing. Let's assume that
> a function f takes an object o as a parameter and that f is a pure function
> (results only depends on argument).
>
> function f(o){
> /* perform a com
I think he's proposing that the 'eval' function would be a magical
function that can inspect its calling environment to determine whether
it's being called in a lexically strict context or not, and based on
that it would act like the strict eval operator, or not.
On Wed, May 11, 2011 at 11:30, Mar
On Wed, May 11, 2011 at 11:16, David Bruant wrote:
> A memoizer could be written to improve f time performance (by the cost of
> memory, of course).
>
> function memoizer(f){
> var cache = WeakMap();
> return function(o){
> var res;
> if(WeakMap.has(o))
> return cache.get(o)
On May 11, 2011, at 11:26 AM, Jorge wrote:
> On 11/05/2011, at 18:53, Brendan Eich wrote:
>
>> (...)
>>
>> 3c. The use of {| (possibly with space in between) is an unambiguous
>> extension, but formal parameters inside |...| delimiters creates a problem
>> for http://wiki.ecmascript.org/doku.p
On Wed, May 11, 2011 at 10:31 AM, Andreas Rossberg wrote:
> On 11 May 2011 18:31, Mark S. Miller wrote:
> > On Wed, May 11, 2011 at 4:42 AM, Andreas Rossberg
> > wrote:
> >>
> >> Thanks to everybody for clearing up my confusion. The thing I had
> >> missed in the spec was Section 10.4.2. And of
Hi,
I've thought about this test:
-
var wm = WeakMap();
var key = {}, value = {};
while(true){
wm.set(key, value);
key = value;
value = {};
}
-
At each loop turn, the reference of the "key" object is lost, so it's
garbage collectable. After a second turn, the "value" object of this
On 11/05/2011, at 18:53, Brendan Eich wrote:
> (...)
>
> 3c. The use of {| (possibly with space in between) is an unambiguous
> extension, but formal parameters inside |...| delimiters creates a problem
> for http://wiki.ecmascript.org/doku.php?id=harmony:parameter_default_values.
> We would n
Hi,
I've recently been thinking about the case of memoizing. Let's assume
that a function f takes an object o as a parameter and that f is a pure
function (results only depends on argument).
function f(o){
/* perform a computation, return the result */
}
A memoizer could be written to i
On 11 May 2011 18:31, Mark S. Miller wrote:
> On Wed, May 11, 2011 at 4:42 AM, Andreas Rossberg
> wrote:
>>
>> Thanks to everybody for clearing up my confusion. The thing I had
>> missed in the spec was Section 10.4.2. And of course, my example was
>> too simplistic because it couldn't distinguis
On Wed, May 11, 2011 at 9:53 AM, Brendan Eich wrote:
> On May 11, 2011, at 9:39 AM, Douglas Crockford wrote:
>
> > We have observed that one of the world's best capability theorists and
> practitioners, intending to to write solid code with capability discipline,
> was tripped up by completion va
On May 11, 2011, at 9:53 AM, Brendan Eich wrote:
> 1. E is an expression language. JS would need opt-in syntax to make a
> sub-language (e.g. arrow function bodies) an expression language, and you'd
> still have plausible objections that with statements on the outside and
> expressions on the i
On Wed, May 11, 2011 at 12:46 PM, David Herman wrote:
> Evidence is good, but that's not exactly scientific. In particular, I'd
> wager there's a material difference in this phenomenon between a language in
> which *all* functions implicitly return and one in which this is only the
> case for a s
On May 11, 2011, at 9:39 AM, Douglas Crockford wrote:
> We have observed that one of the world's best capability theorists and
> practitioners, intending to to write solid code with capability discipline,
> was tripped up by completion value leakage. I think it is a real problem, and
> I think
Evidence is good, but that's not exactly scientific. In particular, I'd wager
there's a material difference in this phenomenon between a language in which
*all* functions implicitly return and one in which this is only the case for a
specific convenience form.
That said, we could also consider
On 5/11/2011 9:19 AM, Brendan Eich wrote:
I still think the completion value leak problem is manageable with
docs, tools, and resort to good old "function" long-hand syntax. Opinions?
We have observed that one of the world's best capability theorists and
practitioners, intending to to write soli
On May 11, 2011, at 9:32 AM, David Herman wrote:
> I agree. But I am sympathetic to Doug's concern about further overloading the
> curly-brace syntax.
That is purely a syntactic problem. More soon, tomorrow I hope.
/be
___
es-discuss mailing list
es-d
> There's no perfect answer. Shorter return syntax ("^" with an ASI change, or
> my "empty label" idea, "function f(){:g()}") is ugly, adds overhead, and can
> still be left off by mistake (making for the opposite problem from the
> capability leak one: returning undefined instead of the intende
On Wed, May 11, 2011 at 4:42 AM, Andreas Rossberg wrote:
> Thanks to everybody for clearing up my confusion. The thing I had
> missed in the spec was Section 10.4.2. And of course, my example was
> too simplistic because it couldn't distinguish caller and global
> context.
>
> At the risk of reviv
On May 11, 2011, at 9:12 AM, Brendan Eich wrote:
> On May 11, 2011, at 8:52 AM, Claus Reinke wrote:
>> More concise function syntax is important, as long as the deeper
>> issues get resolved, too.
>
> What deeper issue beyond |this| binding (lexical, dynamic, soft, etc.) do you
> mean, precisely
On May 11, 2011, at 8:52 AM, Claus Reinke wrote:
>> ECMAScript has a large set of problems. I think that the fact that
>> 'function' has eight letters is at the bottom of the priority list.
>
> - fixing ECMAScript's oddities would be worth a language revision,
> even without adding anything n
See also
http://wiki.ecmascript.org/doku.php?id=proposals:hashcodes and especially
http://wiki.ecmascript.org/doku.php?id=proposals:hashcodes#a_note_regarding_security
which date from ES4, and
http://wiki.ecmascript.org/doku.php?id=strawman:encapsulated_hashcodes
which needs updating.
/be
On
Background assumptions:
Fixing ASI, as desirable as that may be, is not going to
happen soon. Neither is the transition going to be quick
if/when a better alternative emerges, as existing ASI usage
patterns need to be supported.
However, these usage patterns are currently not c
ECMAScript has a large set of problems. I think that the fact that
'function' has eight letters is at the bottom of the priority list.
- fixing ECMAScript's oddities would be worth a language revision,
even without adding anything new
- ECMAScript's oddities have been deployed, resulting in
On 5/10/11, Allen Wirfs-Brock wrote:
>
> On May 10, 2011, at 4:53 PM, Douglas Crockford wrote:
>>
>>
>> I look at ECMAScript as serving four groups:
>>
>> 1. The beginners for whom the language was designed.
>> 2. The web developers who owe their livelihoods to the language.
Library users.
>> 3.
On 11:59 AM, Allen Wirfs-Brock wrote:
On May 10, 2011, at 4:53 PM, Douglas Crockford wrote:
I look at ECMAScript as serving four groups:
1. The beginners for whom the language was designed.
2. The web developers who owe their livelihoods to the language.
3. The scientists who will use the la
Le 11/05/2011 08:41, Allen Wirfs-Brock a écrit :
I think we are dancing around one of the key differences between static
languages and dynamic languages. Static languages make guarantees about a set
of potentially complex invariants (for example, subtype conformance). They
can do this beca
Thanks to everybody for clearing up my confusion. The thing I had
missed in the spec was Section 10.4.2. And of course, my example was
too simplistic because it couldn't distinguish caller and global
context.
At the risk of reviving old discussions, are there any sources
explaining the rationale b
On May 11, 2011, at 12:55 AM, Erik Corry wrote:
> 2011/5/10 Oliver Hunt :
>> As much as I'm opposed to the idea of keyword shortening for the sake of
>> keyword shortening, the more i think about it, the less i like the arrow
>> syntax.
>>
>> I think I'd simply prefer a prefix character to the
2011/5/10 Oliver Hunt :
> As much as I'm opposed to the idea of keyword shortening for the sake of
> keyword shortening, the more i think about it, the less i like the arrow
> syntax.
>
> I think I'd simply prefer a prefix character to the infix arrow operator,
> mostly from a readability stand
43 matches
Mail list logo
