RegExp.$1 spec

Brendan Eich brendan at
Sat Apr 21 10:46:34 PDT 2007

At the latest face-to-face, we agreed:

1. strict mode selects a different eval implementation, which rejects  
program source containing binding forms other than let and its  
variations (var, function), to prevent new names from being  
introduced into eval's dynamic scope, frustrating static analyses  
including optimization.

2. Otherwise strict mode rejects certain programs at compile time but  
changes no runtime semantics.

3. We decided to leave RegExp.$n unspecified, so it can wither and die.


On Apr 15, 2007, at 2:14 AM, Lars T Hansen wrote:

> On 4/6/07, Francis Cheng <fcheng at> wrote:
>> Just a random thought: What if we made it permissible in standard  
>> mode,
>> but illegal in strict mode? That would give us backward compatibility
>> and reinforce the idea that it's a scripting-friendly practice  
>> that is
>> not a good idea for larger programs.
> If I read the strict-and-standard proposal correctly, strict mode has
> no run-time impacts; all it does is layer compile-time checking (and
> rejection of some programs) onto a common run-time language.
> On the other hand, there is the "better eval" discussion from the
> January f2f which *might* be interpreted as strict mode having effects
> on run-time behavior, and that would create some sort of precedent for
> what you're suggesting.  But it has not yet been written up as a
> coherent proposal (it's only in the meeting notes).
> I like the cleanliness of the current strict-and-standard proposal,
> and I hope we can keep the run-time behavior invariant on whether
> strict mode is in effect.  In that sense I don't like outlawing $n in
> strict mode; I'm also not sure about whether it's good software
> engineering to do so (programs will typically consist of some chunks
> compiled in strict mode and others in standard mode).
> But I'll put all of this on the agenda for the next f2f.
> --lars
>> Francis
>> -----Original Message-----
>> From: es4-discuss-bounces at
>> [mailto:es4-discuss-bounces at] On Behalf Of Lars T Hansen
>> Sent: Friday, April 06, 2007 3:11 AM
>> To: Brendan Eich
>> Cc: es4-discuss at; Erik Arvidsson
>> Subject: Re: RegExp.$1 spec
>> On 4/5/07, Brendan Eich <brendan at> wrote:
>>> Ugh, I'd forgotten about this. If it's implemented in all of IE,
>>> Mozilla, Opera, and Safari, then it might be best to codify it in
>>> ES4. OTOH we would then want to deprecate it. If we can let it alone
>>> as a de-facto standard, not make it normative in the de-jure spec,
>>> and thereby more effectively deprecate it, that would be best IMHO.
>> Storing global state on shared global objects is script-friendly but
>> bad practice for larger programs IMO (and is likely to interact  
>> poorly
>> with future developments for multiprocessing).  It interacts poorly
>> with libraries too, since it allows library implementation (does it
>> use regexes or String.prototype.indexOf?) can become visible.  The
>> order and timing of event handler firings (probably not 100%
>> compatible between user agents) matters for program correctness.   
>> Etc.
>> The cat's out of the bag, but making the problem worse by condoning
>> the practice does not seem right.
>> Does anyone know how widespread the use of this mechanism is?
>> --lars
>>> /be
>>> On Apr 5, 2007, at 1:30 PM, Erik Arvidsson wrote:
>>>> I cannot find any spec for how RegExp.$1 etc should work. It is not
>>>> part of the 3rd edition but all user agents seems to implement  
>>>> this.
>>>> Is there a spec for this somewhere? Should this be added to edition
>> 4?
>>>> --
>>>> erik
>>>> _______________________________________________
>>>> Es4-discuss mailing list
>>>> Es4-discuss at
>>> _______________________________________________
>>> Es4-discuss mailing list
>>> Es4-discuss at
>> _______________________________________________
>> Es4-discuss mailing list
>> Es4-discuss at
>> _______________________________________________
>> Es4-discuss mailing list
>> Es4-discuss at
> _______________________________________________
> Es4-discuss mailing list
> Es4-discuss at

-------------- next part --------------
An HTML attachment was scrubbed...

More information about the Es4-discuss mailing list