:
> >
> > These three RegExps don't appear valid, even after reading the Annex B,
> but they do behave consistently in both Chrome and Firefox. They are listed
> here with equivalent regexps:
> >
> > - `/[[]/` -> `/\[\[\]/`
> > - `/[]]/` -> `/(?!)/` (i.e. n
> Le 3 juin 2016 à 10:20, Isiah Meadows <isiahmead...@gmail.com> a écrit :
>
> These three RegExps don't appear valid, even after reading the Annex B, but
> they do behave consistently in both Chrome and Firefox. They are listed here
> wi
spec bug for compat reasons.
>
> On Fri, 3 Jun 2016 at 14:20 Boris Zbarsky <bzbar...@mit.edu
> <mailto:bzbar...@mit.edu>> wrote:
> On 6/3/16 4:20 AM, Isiah Meadows wrote:
> > These three RegExps don't appear valid, even after reading the Annex B,
> > but they do behave
bably be classed as a spec bug for compat reasons.
>
> On Fri, 3 Jun 2016 at 14:20 Boris Zbarsky <bzbar...@mit.edu> wrote:
>
>> On 6/3/16 4:20 AM, Isiah Meadows wrote:
>> > These three RegExps don't appear valid, even after reading the Annex B,
>> > but they do
probably be classed as a spec bug for compat reasons.
On Fri, 3 Jun 2016 at 14:20 Boris Zbarsky <bzbar...@mit.edu> wrote:
> On 6/3/16 4:20 AM, Isiah Meadows wrote:
> > These three RegExps don't appear valid, even after reading the Annex B,
> > but they do behave consis
On 6/3/16 4:20 AM, Isiah Meadows wrote:
These three RegExps don't appear valid, even after reading the Annex B,
but they do behave consistently in both Chrome and Firefox.
Note that Chrome and Firefox use the same regexp implementation, so them
agreeing on how a regexp is handled means a lot
Jeremy Darling wrote:
/[]]/ This one throws me, that should require the first ] to be escaped
(\]) to be useful. I can see it parse and accept but have no clue why or
what it would do. It should throw an error.
I can't see it accept anything. Afaics, it's equivalent to /[]\]/ -
which
eadows <isiahmead...@gmail.com>
wrote:
> These three RegExps don't appear valid, even after reading the Annex B,
> but they do behave consistently in both Chrome and Firefox. They are listed
> here with equivalent regexps:
>
> - `/[[]/` -> `/\[\[\]/`
> -
These three RegExps don't appear valid, even after reading the Annex B, but
they do behave consistently in both Chrome and Firefox. They are listed
here with equivalent regexps:
- `/[[]/` -> `/\[\[\]/`
- `/[]]/` -> `/(?!)/` (i.e. nothing)
- `/a{,,/` -> `/a\{,,+/`
Is this a
I think it's problematic that this is being standardized without a single
implementation.
On Wed, Jan 28, 2015 at 11:57 AM, André Bargull andre.barg...@udo.edu
wrote:
On Wed, Jan 28, 2015 at 11:36 AM, Marja Hölttä marja at chromium.org
https://mail.mozilla.org/listinfo/es-discuss wrote:
*
On Jan 28, 2015, at 8:11 , Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Jan 28, 2015, at 2:36 AM, Marja Hölttä ma...@chromium.org wrote:
Hello es-discuss,
TL;DR: /foo.bar/u.test(“foo\uD83Dbar”) == ?
The ES6 unicode regexp spec is not very clear regarding what should happen
On Jan 28, 2015, at 8:30 , Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Jan 28, 2015, at 4:54 AM, Wes Garland w...@page.ca wrote:
Do we extend the regexp syntax to have a symbol which matches an unmatched
surrogate?
we already have it: \u{D83D}
Or to match any unpaired
On Jan 31, 2015, at 12:01 AM, Norbert Lindenberg wrote:
That definition is in section 6.1.4:
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-ecmascript-language-types-string-type
A cross-reference would be useful.
Norbert
done
allen
not. If it's not, what will ch be if the input string contains a lonely
surrogate in the relevant position?
Q1: Are lonely surrogates allowed in /u regexps?
E.g., /foo\uD83D/u; (note lonely lead surrogate), should this be allowed?
Will it match a lead surrogate inside a surrogate pair
On 1/28/2015 2:51 PM, André Bargull wrote:
For a reference, here's how Java (tried w/ Oracle 1.8.0_31 and openjdk
1.7.0_65) Pattern.UNICODE_CHARACTER_CLASS works:
foo\uD834bar and foo\uDC00bar match ^foo[^a]bar$ and ^foo.bar$, so,
generally, lonely surrogates match /./.
Backreferences are
For a reference, here's how Java (tried w/ Oracle 1.8.0_31 and openjdk
1.7.0_65) Pattern.UNICODE_CHARACTER_CLASS works:
foo\uD834bar and foo\uDC00bar match ^foo[^a]bar$ and ^foo.bar$, so,
generally, lonely surrogates match /./.
Backreferences are allowed to consume the leading surrogate of a
I think the cleanest mental model is where UTF-16 or UTF-8 strings are
interpreted as if they were transformed into UTF-32.
While that is generally feasible, it often represents a cost in performance
which is not acceptable in practice. So you see various approaches that
involve some deviation
For a reference, here's how Java (tried w/ Oracle 1.8.0_31 and openjdk
1.7.0_65) Pattern.UNICODE_CHARACTER_CLASS works:
foo\uD834bar and foo\uDC00bar match ^foo[^a]bar$ and ^foo.bar$, so,
generally, lonely surrogates match /./.
Backreferences are allowed to consume the leading surrogate of a
Based on Ex1, looks like the input string is not read as a sequence of code
points when we try to find a match for \1. So it's mostly read as a
sequence of code points except when it's not. :/
On Wed, Jan 28, 2015 at 3:11 PM, André Bargull andre.barg...@udo.edu
wrote:
On 1/28/2015 2:51 PM,
surrogate in the relevant position?
Q1: Are lonely surrogates allowed in /u regexps?
E.g., /foo\uD83D/u; (note lonely lead surrogate), should this be allowed?
Will it match a lead surrogate inside a surrogate pair?
Suggestion: we shouldn't allow lonely surrogates in /u regexps.
If users
On Wed, Jan 28, 2015 at 11:36 AM, Marja Hölttä marja at chromium.org
https://mail.mozilla.org/listinfo/es-discuss wrote:
/ The ES6 unicode regexp spec is not very clear regarding what should happen
// if the regexp or the matched string contains lonely surrogates (a lead
// surrogate
Good, that sounds right.
Mark https://google.com/+MarkDavis
*— Il meglio è l’inimico del bene —*
On Wed, Jan 28, 2015 at 12:57 PM, André Bargull andre.barg...@udo.edu
wrote:
On Wed, Jan 28, 2015 at 11:36 AM, Marja Hölttä marja at chromium.org
https://mail.mozilla.org/listinfo/es-discuss
On Wed, Jan 28, 2015 at 11:45 AM, Mathias Bynens math...@qiwi.be wrote:
On 28 Jan 2015, at 11:36, Marja Hölttä ma...@chromium.org wrote:
For example, the current version of Mathias’s ES6 Unicode regular
expression transpiler ( https://mothereff.in/regexpu ) converts /a.b/u
into
On Wed, Jan 28, 2015 at 11:36 AM, Marja Hölttä ma...@chromium.org wrote:
The ES6 unicode regexp spec is not very clear regarding what should happen
if the regexp or the matched string contains lonely surrogates (a lead
surrogate without a trail, or a trail without a lead). For example, for the
?
Q1: Are lonely surrogates allowed in /u regexps?
E.g., /foo\uD83D/u; (note lonely lead surrogate), should this be allowed?
Will it match a lead surrogate inside a surrogate pair?
Suggestion: we shouldn't allow lonely surrogates in /u regexps.
If users actually want to match lonely surrogates
On 1/28/2015 3:36 PM, Marja Hölttä wrote:
Based on Ex1, looks like the input string is not read as a sequence of code
points when we try to
find a match for \1. So it's mostly read as a sequence of code points except
when it's not. :/
Yep, back references are matched as a sequence of code
On Jan 28, 2015, at 5:26 AM, Mark Davis ☕️ m...@macchiato.com wrote:
I think the cleanest mental model is where UTF-16 or UTF-8 strings are
interpreted as if they were transformed into UTF-32.
This is exactly the approach used in the ES6 spec (except that it doesn’t deal
with UTF-8)
Cool, thanks for clarifications!
To make sure, as per the intended semantics, we never allow splitting a
valid surrogate pair (= matching only one of the surrogates but not the
other), and thus we'll differ from the Java implementation here:
/foo(.+)bar\1/u.test(foo\uD834bar\uD834\uDC00); we say
,
it’s not. If it's not, what will ch be if the input string contains a lonely
surrogate in the relevant position?
Q1: Are lonely surrogates allowed in /u regexps?
E.g., /foo\uD83D/u; (note lonely lead surrogate), should this be allowed?
Will it match a lead surrogate inside a surrogate pair
On Jan 28, 2015, at 4:54 AM, Wes Garland w...@page.ca wrote:
Some interesting questions here.
These aren't discussion points. These are all things that must have answers
that are directly derivable from the ES6 spec. If, after developing an
adequate understand of that part of the
Cool, thanks for clarifications!
To make sure, as per the intended semantics, we never allow splitting a
valid surrogate pair (= matching only one of the surrogates but not the
other), and thus we'll differ from the Java implementation here:
/foo(.+)bar\1/u.test(foo\uD834bar\uD834\uDC00); we
C. Scott Ananian wrote:
On Wed, Sep 24, 2014 at 2:36 AM, Viktor Mukhachevesdiscus...@yandex.ru wrote:
RegExp.prototype.exec returns array with extra properties (input, index),
may be it is better to return something other for `run`, frozen value object with
`0`, `1`, ... keys for example.
Le 16 sept. 2014 à 20:16, Domenic Denicola dome...@domenicdenicola.com a
écrit :
I had a conversation with Jaswanth at JSConf EU that revealed that RegExps
cannot be used in parallel JS because they modify global state, i.e.
`RegExp.$0` and friends.
We were thinking it would be nice
On Tue, Sep 23, 2014 at 10:04 AM, Claude Pache claude.pa...@gmail.com wrote:
Another idea is to to define a variant of the `RegExp.prototype.exec()`
method, that does the Right Thing (doesn't read/write stuff on the RegExp
instance, nor on the RegExp global, nor I don't know where):
specially when you `yield` around, who knows what happens ... but yes, this
looks like the best option to me too so +1
On Tue, Sep 23, 2014 at 3:35 PM, C. Scott Ananian ecmascr...@cscott.net
wrote:
On Tue, Sep 23, 2014 at 10:04 AM, Claude Pache claude.pa...@gmail.com
wrote:
Another idea is
Le 23 sept. 2014 à 16:35, C. Scott Ananian ecmascr...@cscott.net a écrit :
On Tue, Sep 23, 2014 at 10:04 AM, Claude Pache claude.pa...@gmail.com wrote:
Another idea is to to define a variant of the `RegExp.prototype.exec()`
method, that does the Right Thing (doesn't read/write stuff on the
a code that does not instantly check results through `RegExp` access is
basically dead anyway since unreliable or potentially broken later on but a
flag to opt out sill make this a no-problem, right?
That code is legacy that should work as impossible to mark as dead
anyway, not sure changing this
Jussi Kalliokoski wrote:
Unicode flag disabling features to enable parallelism is another
footnote for WTFJS.
A bit overdone, but I agree on this point.
A separate flag per regexp, and/or a way to opt-out of RegExp.$foo
altogether, seem better.
/be
a conversation with Jaswanth at JSConf EU that revealed that
RegExps cannot be used in parallel JS because they modify global state,
i.e. `RegExp.$0` and friends.
We were thinking it would be nice to find some way of getting rid of
this wart. One idea would be to bundle the don't-modify-global-state
On Wed, Sep 17, 2014 at 6:35 AM, Steve Fink sph...@gmail.com wrote:
Is
if ((m = /foo:(\d+)/.exec(str)) parseInt(m[1], 10) 15) { ... }
so bad?
well, you just polluted the global scope by accident creating (maybe) a
hybrid Array with properties attaches in order to just access index 1
that revealed that
RegExps cannot be used in parallel JS because they modify global state,
i.e. `RegExp.$0` and friends.
We were thinking it would be nice to find some way of getting rid of
this wart. One idea would be to bundle the don't-modify-global-state
behavior with the `/u` flag. Another would
On Sep 16, 2014, at 11:22 PM, Brendan Eich wrote:
Jussi Kalliokoski wrote:
Unicode flag disabling features to enable parallelism is another footnote
for WTFJS.
A bit overdone, but I agree on this point.
A separate flag per regexp, and/or a way to opt-out of RegExp.$foo
altogether,
On Tue, Sep 16, 2014 at 8:16 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
I also noticed today that the static `RegExp` properties are not specced,
which seems at odds with our new mandate to at least Annex B-ify the
required-for-web-compat stuff.
As a general note to people
On Wed, Sep 17, 2014 at 11:39 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
Annex B contains many changes to RegExp from the base standard. Perhaps a
better way to approach this is to have a standard (not Annex B) regexp flag
(perhaps 's', for standard or strict) that means that this
FWIW that 's' flag would work for me, but about not being specd, those
properties are described already here:
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-getreplacesubstitution
and these are a long time de-facto standard. somebody wrote already about
them a while ago:
On Sep 17, 2014, at 8:59 AM, Andrea Giammarchi wrote:
FWIW that 's' flag would work for me, but about not being specd, those
properties are described already here:
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-getreplacesubstitution
that doesn't say anything about RegExp
Allen Wirfs-Brock wrote:
A separate flag per regexp, and/or a way to opt-out of RegExp.$foo
altogether, seem better.
Speaking strictly from a standards perspective, it seems that we are getting a
bit ahead of ourselves.
Sure, but this is es-discuss, it runs ahead of standardization by
I meant nothing new to learn, it doesn't say anything but it describes
them already so when you say not in spec I think well, not as property,
even if every engine has them, but already in specs somehow.
Hence a reason to not break de-facto legacy and think about an opt out
instead
Regards
On
`lastIndex` also prevents usage of one instance in parallel...
I know the javascript do not support parallel execution, but the code is not so
beatiful...
the idea to deprecate lastIndex was proposed 4 years ago:
see
http://blog.stevenlevithan.com/archives/fixing-javascript-regexp
I had a conversation with Jaswanth at JSConf EU that revealed that RegExps
cannot be used in parallel JS because they modify global state, i.e.
`RegExp.$0` and friends.
We were thinking it would be nice to find some way of getting rid of this wart.
One idea would be to bundle the don't-modify
On Sep 16, 2014, at 11:16 AM, Domenic Denicola wrote:
I had a conversation with Jaswanth at JSConf EU that revealed that RegExps
cannot be used in parallel JS because they modify global state, i.e.
`RegExp.$0` and friends.
We were thinking it would be nice to find some way of getting rid
wrote:
On Sep 16, 2014, at 11:16 AM, Domenic Denicola wrote:
I had a conversation with Jaswanth at JSConf EU that revealed that
RegExps cannot be used in parallel JS because they modify global state,
i.e. `RegExp.$0` and friends.
We were thinking it would be nice to find some way of getting
ock.com wrote: On Sep 16, 2014, at 11:16 AM, Domenic Denicola wrote: I had a conversation with Jaswanth at JSConf EU that revealed that RegExps cannot be used in parallel JS because they modify global state, i.e. `RegExp.$0` and friends. We were thinking it would be nice to find some way of gett
Alex Kocharin wrote:
What's the advantage of `re.test(str); RegExp.$1` over `let
m=re.match(str); m[1]`?
Right. I think Andrea is smoking something :-P.
I assume RegExp[$'] and RegExp[$`] are nice to have, I remember
them from perl, but never actually used them in javascript.
I regret
heh - apparently there's a completely different jas in the js world that
was also affected by global state in RegExp (this is the one that bit me
http://code.google.com/p/google-caja/wiki/RegexpsLeakMatchGlobally).
Moreover, AFAIK JavaScript is single threaded per each EventLoop so I don't
see
a conversation with Jaswanth at JSConf EU that revealed that
RegExps cannot be used in parallel JS because they modify global state,
i.e. `RegExp.$0` and friends.
We were thinking it would be nice to find some way of getting rid of
this wart. One idea would be to bundle the don't-modify-global
mailto:al...@wirfs-brock.com wrote:
On Sep 16, 2014, at 11:16 AM, Domenic Denicola wrote:
I had a conversation with Jaswanth at JSConf EU that
revealed that RegExps cannot be used in parallel JS because
they modify global state, i.e. `RegExp.$0` and friends
-
Object.prototype.hasOwnProperty is a great candidate.
Invokable RegExps would have been a solution, although nobody would expect
a RegExp to be invokable (because it's pretty exotic) and it probably
wouldn't have been used anyways by a lot of people.
___
es-discuss
Felix Böhm wrote:
It seems like somebody thought about this use case when adding the
second argument.
Yes, shaver and I talked about this way back when he added the array
extras -- we wanted an optional |this| parameter for the callback.
Invokable RegExps would have been a solution, although
Brendan Eich wrote:
js [fOo,bAr].filter(function(){return /foo/i});
[fOo, bAr]
LOL, I returned a truthy value. Fixing:
js [fOo,bAr].filter(function(s){return /foo/i.test(s)});
[fOo]
Even longer :-/.
So yes, callable regexps were useful -- that's why I made 'em callable
way back when
On Sat, Mar 24, 2012 at 5:54 AM, Brandon Benvie
bran...@brandonbenvie.com wrote:
I've been struggling for a way to describe this idea, but it's almost like
we're lacking what amounts to a valueOf where the expected result is a
callable. The regex-as-filter is a good example of that use case.
made regexps callable way back when, I chose calling a regexp as
short for exec'ing, which creates a match array result. Then I optimized
the exec/call built-in to peek into its continuation to see if the
result was used only for its boolishness. If so, the built-in would pass
a flag parameter
Hi guys,
just a first try for a proposal: Array.prototype.[filter/some/every]
currently require a function as an argument. Most of the time, everything I
want to do is check if they match a certain pattern. So what I end up
writing is a RegExp that matches the pattern, and calling its test()
It seems like too much of a shortcut to do that. RegEx's in es are not
natively callable, so it seems like this is an overload rather than an
additional feature.
On Friday, March 23, 2012, Felix Böhm esdisc...@feedic.com wrote:
Hi guys,
just a first try for a proposal:
Does passing /foo/i.test not work? (Away from computer.) Perhaps it should, if
it doesn't?
On Mar 23, 2012, at 16:28, Felix Böhm
esdisc...@feedic.commailto:esdisc...@feedic.com wrote:
Hi guys,
just a first try for a proposal: Array.prototype.[filter/some/every] currently
require a function
I'd opt for a solution like that it's a lot clearer than overloading
collection functions.
On Friday, March 23, 2012, Domenic Denicola dome...@domenicdenicola.com
wrote:
Does passing /foo/i.test not work? (Away from computer.) Perhaps it
should, if it doesn't?
On Mar 23, 2012, at 16:28, Felix
On Fri, Mar 23, 2012 at 8:21 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
Does passing /foo/i.test not work? (Away from computer.) Perhaps it
should, if it doesn't?
It does, if you bind it to the regex first. Ie:
var re = /foo/i;
var filtered = array.filter(re.test.bind(re));
On Mar 23, 2012, at 9:05 PM, John Tamplin j...@google.com wrote:
On Fri, Mar 23, 2012 at 8:21 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
Does passing /foo/i.test not work? (Away from computer.) Perhaps it should,
if it doesn't?
It does, if you bind it to the regex first.
Would it be a reasonable language upgrade to pre-bind test? I imagine there
would be philosophical objections, but would be interested in hearing them
enunciated. (Are there other pre-bound methods in ES5's standard library?)
On Mar 23, 2012, at 21:48, Russell Leggett
I've been struggling for a way to describe this idea, but it's almost like
we're lacking what amounts to a valueOf where the expected result is a
callable. The regex-as-filter is a good example of that use case. You don't
want the base object to be a function or callable necessarily, but you do
browsers what the consensus spec. really is.
Allen
-Original Message-
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-
boun...@mozilla.org] On Behalf Of Michael Day
Sent: Thursday, November 11, 2010 11:59 PM
To: ES-Discuss
Subject: { and } in regexps
Hi,
Browsers seem
Of Michael Day
Sent: Thursday, November 11, 2010 11:59 PM
To: ES-Discuss
Subject: { and } in regexps
Hi,
Browsers seem to allow { and } to occur in regexps unescaped, if the position
does not conflict with their use as a quantifier. For example:
/foo|{bar}/
However, ES3 and ES5
Hi,
Browsers seem to allow { and } to occur in regexps unescaped, if the
position does not conflict with their use as a quantifier. For example:
/foo|{bar}/
However, ES3 and ES5 forbid this, as PatternCharacter does not include {
or } or any of the other significant punctuation.
Given
[sent this to es3.x-discuss by mistake, sorry for any duplicates]
Hi,
Is \$ valid inside regexps? For example:
xs = /foo\$bar/.exec(foo$bar);
This matches in Firefox. However, the spec would appear to forbid this
interpretation, unless I'm confused again:
IdentifierStart
Brendan Eich wrote:
On Jan 24, 2009, at 10:56 PM, Richard Cornford wrote:
snip
I am not saying that there should be a shared singleton. In
the situation as we have it now there are implementations
that create regular expression literals while parsing, and
others that create them when the
Mark S. Miller wrote:
Mike Shaver wrote:
Firefox and Opera are doing what ES3 requires (s 7.8.5:
http://bclary.com/2004/11/07/#a-7.8.5 ),
Correct.
but I believe that it's being changed in 3.1 to produce a new
one each time the literal expression is executed.
Correct. In the meantime, you
On Jan 24, 2009, at 10:56 PM, Richard Cornford wrote:
All of that is true, and making sure the next language version
eliminates that is a good idea. But that does not help people who
have to address current ES 3 implementations.
The bug I cited,
2009/1/23 Laurens Holst lho...@students.cs.uu.nl:
Hi,
I and a colleague were puzzled by some strange behaviour in Firefox, we
found that in some browsers literal regular expressions are cached and
reused. Testcase:
function test(str) {
var regexp = /^[^d]*\bd{1,4}\b[^d]*$/g;
Laurens Holst wrote:
Hi,
I and a colleague were puzzled by some strange behaviour in Firefox, we
found that in some browsers literal regular expressions are cached and
reused. Testcase:
function test(str) {
var regexp = /^[^d]*\bd{1,4}\b[^d]*$/g;
alert('Expexted: 0/true, result: '
79 matches
Mail list logo
