The /n property would reflect on the RegExp object as `Noncapturing ==
true`.
Lowercase noncapturing, right?
Yeah.
--Kyle
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Jun 2, 2011, at 10:49 PM, Brendan Eich wrote:
> On Jun 2, 2011, at 10:46 PM, Kyle Simpson wrote:
>
>> I propose a /n flag for regular expressions, which would swap the default
>> capturing/non-capturing behavior between ( ) and (?: ) operators (that is, (
>> ) would not capture, and (?: ) wo
On Jun 2, 2011, at 10:46 PM, Kyle Simpson wrote:
> I propose a /n flag for regular expressions, which would swap the default
> capturing/non-capturing behavior between ( ) and (?: ) operators (that is, (
> ) would not capture, and (?: ) would capture).
I like it. No worries about the .NET somew
I propose a /n flag for regular expressions, which would swap the default
capturing/non-capturing behavior between ( ) and (?: ) operators (that is,
( ) would not capture, and (?: ) would capture).
The /n property would reflect on the RegExp object as `Noncapturing ==
true`.
Is there any p
On Jun 2, 2011, at 10:15 PM, Kyle Simpson wrote:
>>> So if a non-TC39 member wants to create suggestions and proposals and ideas
>>> for the community to discuss, am I to understand that not only this list,
>>> but also the wiki that this list so frequently references, are not really
>>> intend
So if a non-TC39 member wants to create suggestions and proposals and
ideas for the community to discuss, am I to understand that not only this
list, but also the wiki that this list so frequently references, are not
really intended for that?
I didn't say anything about this list. Discussion o
On Jun 2, 2011, at 8:12 PM, Brendan Eich wrote:
>> - Conflict between blocks and statements:
>>
>> a = {x: while (x) { ... break x;}}
>>
>> is either an object initializer or a block containing a labeled while
>> statement.
>
> http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syn
On Jun 1, 2011, at 5:52 PM, Waldemar Horwat wrote:
> On 06/01/11 16:07, Peter Michaux wrote:
>> Could some of JavaScript's statements also be allowed as expressions?
>>
>> In Perl there is the common idiom when opening a file
>>
>> open F, "< $f" or die "Can't open $f : $!";
>>
>> In JavaScr
On 06/02/11 17:56, Kyle Simpson wrote:
Is it available for general public members to register for an account to create
strawman proposals for ES?
No, it's an Ecma TC39 resource. Ecma needs IPR handoff per its patent covenant
so this can't be a free-for-all, for better or worse.
So if a non-
On Jun 2, 2011, at 5:56 PM, Kyle Simpson wrote:
>>> Is it available for general public members to register for an account to
>>> create strawman proposals for ES?
>>
>> No, it's an Ecma TC39 resource. Ecma needs IPR handoff per its patent
>> covenant so this can't be a free-for-all, for better
Is it available for general public members to register for an account to
create strawman proposals for ES?
No, it's an Ecma TC39 resource. Ecma needs IPR handoff per its patent
covenant so this can't be a free-for-all, for better or worse.
So if a non-TC39 member wants to create suggestions a
On Jun 2, 2011, at 4:16 PM, Kyle Simpson wrote:
> Is it available for general public members to register for an account to
> create strawman proposals for ES?
No, it's an Ecma TC39 resource. Ecma needs IPR handoff per its patent covenant
so this can't be a free-for-all, for better or worse.
>
Here's one possible implementation strategy for proxies that does not
require any changes to the language semantics yet still could deal
with the space overhead concern of having separate proxy + handler
objects. This idea is very preliminary, and may have holes...
Normally, a call to Proxy.create
2011/6/2 Mike Samuel :
> 2011/6/2 Waldemar Horwat :
>> On 06/02/11 13:43, Mike Samuel wrote:
>>>
>>> Yes. That grammar is a subset of the grammar that results from
>>> replacing the 11.1.6 ' PrimaryExpression : "(" Expression ")" '
>>> production with
>>>
>>> "(" GroupElement GroupElements ")"
2011/6/2 Waldemar Horwat :
> On 06/02/11 13:43, Mike Samuel wrote:
>>
>> Yes. That grammar is a subset of the grammar that results from
>> replacing the 11.1.6 ' PrimaryExpression : "(" Expression ")" '
>> production with
>>
>> "(" GroupElement GroupElements ")"
>>
>> where GroupElement is def
Is it available for general public members to register for an account to
create strawman proposals for ES?
In particular, I'd like to create two proposals for some future discussion:
1. a "n" (or "c") flag for regexp's, that reverses the default capturing
behavior of ( ) to be non-capturing by
On 06/02/11 13:43, Mike Samuel wrote:
Yes. That grammar is a subset of the grammar that results from
replacing the 11.1.6 ' PrimaryExpression : "(" Expression ")" '
production with
"(" GroupElement GroupElements ")"
where GroupElement is defined as any Statement except for Block and
Empty
Note that
http://wiki.ecmascript.org/doku.php?id=harmony:regexp_y_flag
has been promoted to harmony:proposals status (see
http://wiki.ecmascript.org/doku.php?id=harmony:proposals), so very likely to be
in ES.next.
With this flag on a regexp, you don't need extra arguments for a suite of
metho
Yes. That grammar is a subset of the grammar that results from
replacing the 11.1.6 ' PrimaryExpression : "(" Expression ")" '
production with
"(" GroupElement GroupElements ")"
where GroupElement is defined as any Statement except for Block and
EmptyStatement without a terminal semicolon, a
Did you mean to disallow an expression as the first statement in your "block"?
Waldemar
On 06/01/11 18:49, Mike Samuel wrote:
2011/6/1 Waldemar Horwat:
Yes, if you make it mandatory to parenthesize statements then this would
work, except for the important case of blocks.
I agree that blo
On 06/01/11 18:47, Breton Slivka wrote:
Yes, if you make it mandatory to parenthesize statements then this would
work, except for the important case of blocks.
Waldemar
This might be a pretty radical (or stupid) thing to ask, but what if a
block with labeled statements were semantically t
There are some interesting network issues discussed in here.
A point is that applications and the OS should know
how to play well together.
http://gettys.wordpress.com/2011/06/02/google-techtalk-video-is-up/
Some of the issues are OS issues, some can be managed in
an application or at least the a
On Thu, Jun 2, 2011 at 7:17 PM, Mike Samuel wrote:
> 2011/6/2 Peter van der Zee :
>> A problem I faced recently is the inability to apply regular
>> expressions to a substring of a string without explicitly taking the
>> substring first. So I'm wondering how much trouble it would be to
>> extend t
2011/6/2 Peter van der Zee :
> A problem I faced recently is the inability to apply regular
> expressions to a substring of a string without explicitly taking the
> substring first. So I'm wondering how much trouble it would be to
> extend the RegExp api to this...
>
> RegExp.prototype.test = funct
Sounds like an excellent suggestion to me. I'm aware of some implementation
tests this would end up breaking, but no 'real world' code per-se.
My best,
Dave
-Original Message-
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org] On
Behalf Of Peter van der Zee
S
A problem I faced recently is the inability to apply regular
expressions to a substring of a string without explicitly taking the
substring first. So I'm wondering how much trouble it would be to
extend the RegExp api to this...
RegExp.prototype.test = function(string[, start=0[, stop=string.lengt
It wasn't just a thinko, but I'm actually happier with MUST. Fixed.
On Wed, Jun 1, 2011 at 3:42 PM, Brendan Eich wrote:
> Thanks for catching this, it goes back to
> http://wiki.ecmascript.org/doku.php?id=strawman:proper_tail_calls&rev=1273414092(first
> rev). Cc'ing Mark. I bet it is just a th
27 matches
Mail list logo
