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
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
