2008/7/28 Ingvar von Schoultz <[EMAIL PROTECTED]>:
> 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.
S
2008/7/28 Ingvar von Schoultz <[EMAIL PROTECTED]>:
>
> {{ }} is just the same as a scoping function used on ES3:
>
>(function() { code })()
As Lars Hansen has pointed out any proposal for a shorthand for
(function() { code })() has to deal with break/continue/return inside
the code. This is th
2008/7/28 Ingvar von Schoultz <[EMAIL PROTECTED]>:
> I wonder if people would like using them.
Anything that is available in a browser will be used and abused ;).
>
>>> {[ code ]}
>>>
>>> [[ code ]]
>>>
>>> [ code ]
>>
>> Any of this can be a valid ES3 code as [] always means an array liter
2008/7/26 Ingvar von Schoultz <[EMAIL PROTECTED]>:
> I think all of these would be unambiguous:
>
>{. code .}
{. not work since {.0; } is a valid ES3
>
>{: code :}
>
>{| code |}
These 2 cases are indeed invalid ES3.
>
>{[ code ]}
>
>[[ code ]]
>
>[ code ]
Any of this
2008/7/26 Ingvar von Schoultz <[EMAIL PROTECTED]>:
> Do you really think {{ }} appears in existing code, correctly
> enclosing statement blocks, with the {{ and the }} placed tightly
> together both at the beginning and at the end?
Yes: I have seen the code like
if (x) {
{
code
}
}
N
2008/7/25 Lars Hansen <[EMAIL PROTECTED]>:
> Is
>
> {{ return }}
>
> syntactic sugar for
>
> (function() {{ return }})()
>
> too?
I have forgot about the return or break/continue. But this is not a
point since a syntax sugar for (function() { code })() can require
that code must not contain retu
I guess that proposal can be summarized in a very short form:
make
{{ code }}
a syntax sugar for
(function() { code })()
On a few occasions I have used the latter form in ES3 programs to get
the benefits of the let locals without using the let keyword.
Regards, Igor
__
2008/7/18 Allen Wirfs-Brock <[EMAIL PROTECTED]>:
> We ultimately concluded that the best way to think about what we are
> currently provide is that it is a set of primitive mechanisms that could be
> used to build higher level reflection facilities. If we had a strong use case
> we could reintro
2008/7/18 Allen Wirfs-Brock <[EMAIL PROTECTED]>:
> Collectively,
> getOwnProperty,defineProperties/defineProperty,getOwnPropertyNames,getPrototypeOf
> are intended to provide all the mechanisms necessary to build any of these
> variants to extent or any other model of property manipulation using
It seems the current IE7/IE8 behavior is to allow Cf only in srtring
and regexp literals and to allow BOM only in string/regexps or at the
beginning of the source, see
https://bugzilla.mozilla.org/show_bug.cgi?id=430740#c32 . This is very
reasonable.
Igor
__
2008/7/15 Mark Miller <[EMAIL PROTECTED]>:
> As we've found with the ES3-specified stripping of Cf characters, the main
> effect of such transparent stripping of characters is to help attackers slip
> XSS attacks past defensive filters. ES3.1 agrees with ES4 that BOMs and Cfs
> should be treated as
2008/7/15 Ash Berlin <[EMAIL PROTECTED]>:
>
> I'd say that a BOM should be treated just like any ordinary whitespace
> char - namely that it should invalid in spaces, and beyond that why is
> any conversion needed, since its a valid unicode character...
The problem comes from the current ES3 imple
The currently proposed rule for byte-order-mark (BOM) characters in
ES4 sources is to replace them by whitespace outside of tokens. But
what is exactly the tokens in a case like --?
AFAICS it would be treated as - - turning cases like:
--a;
into
- -a;
versus
--a;
that would be with current E
Date.prototype.toLocaleFormat(format) in SpiderMonkey provides access
exactly to strftime functionality.
Regards, Igor
On 31/03/2008, Carl S. Yestrau <[EMAIL PROTECTED]> wrote:
> Garrett Smith wrote:
> > Will ES4 have a simple date formatter?
> > ___
On 29/03/2008, Kris Zyp <[EMAIL PROTECTED]> wrote:
> I think Neil's inspiring demonstration of pseudo-threading with generators
> is also worthy of inclusion in your list of generator use cases:
> http://www.neilmix.com/2007/02/07/threading-in-javascript-17/
That code can be written without gene
The two-arguments Name constructor follow E4X where the corresponding
constructor for QName has the form:
QName(namespace, id)
Regards, Igor
On 12/03/2008, Waldemar Horwat <[EMAIL PROTECTED]> wrote:
> > public function Name(a, b=undefined)
>
> > static meta function invoke(a, b=undefined): Name
On 06/03/2008, Lars Hansen <[EMAIL PROTECTED]> wrote:
> The draft has been updated based on ticket resolutions:
> http://wiki.ecmascript.org/doku.php?id=spec:line_terminator_normalizatio
The URL has missed the final "n", the right one is:
http://wiki.ecmascript.org/doku.php?id=spec:line_terminat
On 06/03/2008, Igor Bukanov <[EMAIL PROTECTED]> wrote:
> On 06/03/2008, Peter Hall <[EMAIL PROTECTED]> wrote:
> > Except that it would have a few unexpected behaviours, especially
> > around the & and < characters.
>
>
> In normal strings and
On 06/03/2008, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> If I understand the motivation for triple quoted strings, it's to allow
> multiline strings with inverted commas and quotes within them, and to
> allow quotes and inverted commas within those substrings, all without
> requiring a cont
On 27/02/2008, Brendan Eich <[EMAIL PROTECTED]> wrote:
...
> I agree with what Lars wrote, except here I think the value of a
> hypothetical (possibly mythical) "big red switch" is understated.
...
>The common problem is that you can't do "dollars
> and cents" or "pounds and pennies" arithmetic a
On 23/01/2008, Lars Hansen <[EMAIL PROTECTED]> wrote:
> Ditto, interprocedural analysis and/or inlining
> may prove that the body of a "try" can't throw an exception, thereby
> allowing the exception handler to be removed, thereby exposing a
> possibility for TCO. And so on.
This nicely shows the
On 22/01/2008, Brendan Eich <[EMAIL PROTECTED]> wrote:
> 2. The programmer uses "goto f(x)" where f returns T and the call is
> in g returning Y,
A quality implementation may still implement the tail call in this
case as the type conversion does not depend on the activation frame.
Yet given such i
On 22/01/2008, Jon Zeppieri <[EMAIL PROTECTED]> wrote:
> Really, all of our back-and-forth since those messages has been pretty
> much off topic.
To bring this back to the topic. I do not think an explicit syntax for
tail calls is useful for the following reasons:
1. It does not guarantee at the
On 21/01/2008, Jon Zeppieri <[EMAIL PROTECTED]> wrote:
> Yes, I am assuming that ES4 mandates that unreachable objects do not
> consume space. That doesn't seem like a terribly bold assumption to
> me.
ES4 does not guarantee that. Moreover, in most current implementations
of ES3 the unreachable o
On 21/01/2008, Igor Bukanov <[EMAIL PROTECTED]> wrote:
> On 21/01/2008, Jon Zeppieri <[EMAIL PROTECTED]> wrote:
> > But the above example *does* only require O(1) space. On each call to
> > f, a new closure is constructed, but it's dropped on the floor as soon
On 21/01/2008, Jon Zeppieri <[EMAIL PROTECTED]> wrote:
> On 1/21/08, Igor Bukanov <[EMAIL PROTECTED]> wrote:
> >
> > Consider another example:
> >
> > function f(a) {
> >function f2 { return a * 2; }
> >if (a == 0) return 0;
&
On 21/01/2008, Graydon Hoare <[EMAIL PROTECTED]> wrote:
> Igor Bukanov wrote:
>
> > I am saying that even for calls in the tail position an implementation
> > may not eliminate the parent frame completely as it still may be
> > exposed via closures. As such the
On 21/01/2008, Jon Zeppieri <[EMAIL PROTECTED]> wrote:
> On 1/21/08, Igor Bukanov <[EMAIL PROTECTED]> wrote:
> > let f2;
> >
> > function f(a)
> > {
> > f2 = function() { return a; }
> > goto return g();
> > }
> >
> >
On 21/01/2008, Peter Michaux <[EMAIL PROTECTED]> wrote:
> On Jan 20, 2008 8:01 PM, Brendan Eich <[EMAIL PROTECTED]> wrote:
...
> > Proper tails calls are not an optimization; they certainly do change
> > semantics, insofar as you can't write certain programs without them
> > being guaranteed.
>
> I
On 21/01/2008, Igor Bukanov <[EMAIL PROTECTED]> wrote:
> then I would prefer to make the tail calls an optional optimization in
> the same way as the type checker is optional.
And if Haskell language specs can leave the issue of tail call
optimization up to implementations, then I do
On 21/01/2008, Erik Arvidsson <[EMAIL PROTECTED]> wrote:
> My concern with E (or A for that matter) is that it requires
> additional syntax. I'd prefer if we could keep the syntax small.
The explicit syntax has one extra flow. Since the type checker is
optional, even with explicit syntax the prog
On 03/01/2008, Brendan Eich <[EMAIL PROTECTED]> wrote:
Igor was applying rude
> deduction of the Scheme sort: compositional primitiives, not gotchas
> or asymmetric restrictions.
In fact I was wrong about the symmetry here.
Consider:
{ let function f() { ... f()... }; ... }
versus hypothetical
On 03/01/2008, Brendan Eich <[EMAIL PROTECTED]> wrote:
> > let function f() { };
>
> I missed that if so -- did you see this in the wiki, a trac ticket,
> or another doc?
I have not seen this, I just assumed for some reasons that syntax for
let blocks and declarations is shared.
Regards, Igor
___
On 03/01/2008, Brendan Eich <[EMAIL PROTECTED]> wrote:
> > let (f = function() { ... f() ... }) { ... }
>
> The call to f within itself always refers to itself.
I do not see how ES3 is relevant to this second case. So I would like
to clarify if in
function f() { }
let (f = function() { ... f()
For functions defined with ES4 let block, does the scope of the
closure includes the let block?
I.e will f in the following examples refer to the function itself or
to the the name from the outer scope?
let (f = function() { ... f() ... }) { ... }
let (function f(n) { ... f() ... }) { ... }
On 06/12/2007, Lars Hansen <[EMAIL PROTECTED]> wrote:
> Opera employees have been participating
> in this discussion and based on their experience with bug reports
> resulting from (or rather not resulting from) restrictions in Opera,
> appear to believe that the current ES4 spec is sufficient.
Th
On 06/12/2007, Lars Hansen <[EMAIL PROTECTED]> wrote:
> Such an implementation only needs to detect direct
> uses of eval, as specified in ES3 and elaborated in ES4. (ES4
> specifies the meaning of strictly more uses of eval than ES3, and
> requries that EvalError is thrown in other cases.)
This
Hi,
Currently ES4 allows to access from eval scripts the names introduced
by the let statements and expressions. It leads to implementation
complexity since the let bindings cannot be implemented as a pure
compilation-time feature and the runtime must be able to expose the
names for eval scripts.
38 matches
Mail list logo
