how to create strawman proposals?

Kyle Simpson getify at gmail.com
Thu Jun 2 17:56:19 PDT 2011


>> 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 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?

There've been several times on this list in various discussion threads where 
it was clear that only official-wiki-based strawmans were things people 
wanted to seriously discuss. And now to find out that such strawmans cannot 
even be authored by any of us non-committee members, it seems like it 
further reinforces the desire that there be some other forum for the "Rest 
of us"T to use to talk about *our* ideas, not just the ideas of the 
committee members.

What's the best way for such informal and non-committee-sponsored 
discussions to proceed?


>> 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 default, and thus (?: ) to be 
>> capturing.
>
> Is there any precedent for this in other perl-based regexp packages?

Perl6 regular expressions have introduced [ ] as a non-capturing grouping 
operator (instead of (?: ) operator). They moved character classes to <[ ]>. 
I'm not saying I like that decision (or dislike it), but it's definitely 
nice (and prettier code) to have a single character (on either side, of 
course) operator for the common task (highly common to me anyway) of 
non-capturing grouping.

But more to the point of my intended proposal, .NET has the /n flag for 
turning off capturing for ( ) -- I'm not sure if it then turns on capturing 
for (?: ) or not, someone more familiar with .NET would have to inform here.

In any case, I write far more (like probably 98% vs. 2%) regular expressions 
where I want non-capturing grouping, and it's onerous (and ugly) to always 
add the ?: to those grouping operators, if I could just use a single flag to 
tell the entire regex that by default I don't care about it capturing 
(unless I explicitly opt-in to it with ?: or something like that).

There was a time when I felt like the default should reverse itself, and 
that ( ) should default to non-capturing. I explored those ideas in 
http://blog.getify.com/2010/11/to-capture-or-not/

But it's quite obvious that this is an impossible proposition, as it would 
break probably ~100% of existing regex content. So, it seems (and was the 
main conclusion of that article and comment thread) like a simple next-best 
solution is to make it opt-in with a flag.

Doing so shouldn't have any backwards-breaking functionality, and should, 
for the most part*, only cause unnecessary (and thus sub-optimal 
performance) capturing for older regex engines that ignored the /n flag.

*There's two cases I can think of where an older regex engine ignoring the 
/n flag and still capturing would cause unexpected results (besides the 
performance slowdown of unnecessary capturing):

1. \xx back-references would be incorrectly numbered
2. str.split() behaves a bit differently (includes more results) if there 
are capturing groups in the regex it splits on

Both those incompatibilities seem manageable and not terribly risky, given 
that such a feature would of course have to be introduced into some opt-in 
version of ES like ES.Harmony, and authors just simply shouldn't author such 
regexes if they intend for that code to run in ES5 and below.


>> 2. a "@>" (or something like it) operator for what I call 
>> statement-localized continuations
>
> We've been over continuations at length on this list. There is a 
> harmony:generators proposal already in ES.next, and a deferred functions 
> strawman as well. Dave Herman's shallow continuations  strawman was 
> intentionally deferred.

I am well aware of the discussions on this list about continuations, as well 
as the existing strawmans. I am also well aware that my views on that topic 
aren't particularly popular. But nevertheless, I still have issues with the 
existing proposals/ideas, and I'd like a chance to advance some discussion 
about my ideas as an alternative. I thought that creating a more 
structured/formalized proposal would be a decent next-step. I'm also working 
on some way to prototype my idea in some JS engine.



--Kyle

 



More information about the es-discuss mailing list