On Sep 26, 2008, at 5:32 PM, Hallvord R. M. Steen wrote:
On Fri, 26 Sep 2008 19:58:27 +0200, liorean <[EMAIL PROTECTED]> wrote:
2008/9/26 Erik Arvidsson <[EMAIL PROTECTED]>:
I know that Opera on mobile phones used to return a string
representation that did not reflect the original.
Yeah. O
>> 2008/9/26 Erik Arvidsson <[EMAIL PROTECTED]>:
>>> I know that Opera on mobile phones used to return a string
>>> representation that did not reflect the original.
> On Fri, 26 Sep 2008 19:58:27 +0200, liorean <[EMAIL PROTECTED]> wrote:
>> Yeah. Opera Mobile returned "[ECMAScript code]" or "[ecm
On Fri, 26 Sep 2008 19:58:27 +0200, liorean <[EMAIL PROTECTED]> wrote:
> 2008/9/26 Erik Arvidsson <[EMAIL PROTECTED]>:
>> I know that Opera on mobile phones used to return a string
>> representation that did not reflect the original.
>
> Yeah. Opera Mobile returned "[ECMAScript code]" or "[ecmascr
The notation he used in this specification was raised as one option
for the ES-Harmony spec's notation.
http://www.mozilla.org/js/language/old-es4/
- Rob
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
At the TC-39 meeting I suggested that Kim Bruce's research in object-oriented
typing is something that some people might want to look at as they think about
the role of type annotations in Harmony. Here are some pointers to Bruce's work:
http://www.cs.williams.edu/~kim/research.html
His book is
2008/9/26 Erik Arvidsson <[EMAIL PROTECTED]>:
> I know that Opera on mobile phones used to return a string
> representation that did not reflect the original.
Yeah. Opera Mobile returned "[ECMAScript code]" or "[ecmascript
code]". This was contrary to the ES3 spec (must be parsable as a
function d
If I remember correctly The reason for keeping it implementation
dependent is so that devices with low memory would not have to keep a
reversible implementation in memory. For example an implementation
might have translated the whole function to machine code.
I know that Opera on mobile phon
On Sep 26, 2008, at 3:27 AM, Karl Krukow wrote:
>
> On 26/09/2008, at 11.13, Maciej Stachowiak wrote:
>
>>
>> I would agree with such a requirement, but only in the case where
>> the eval(f.toString()) is performed in the same scope where f was
>> originally defined, since toString does not repre
On 26/09/2008, at 11.13, Maciej Stachowiak wrote:
>
> I would agree with such a requirement, but only in the case where
> the eval(f.toString()) is performed in the same scope where f was
> originally defined, since toString does not represent the scope chain.
Agreed! The classic variable ca
On Sep 26, 2008, at 12:38 AM, Karl Krukow wrote:
> My suggestion is to strengthen the contract to state something like:
> For any function f and any values x1, x2, ... , xn we have:
>
> eval(f.toString())(x1,x2,...,xn) === f(x1,x2,..., xn).
I would agree with such a requirement, but only in the
Hello everyone,
I was exploring extending Crockford's Pratt parser to build a partial
evaluator for JavaScript. One would extend Function.prototype with a
specialize function, e.g.
(function(a,b) {return a+b}).specialize({ a: 42 })
would return a function equivalent to:
function(b) {return
11 matches
Mail list logo
