Thanks Brendan, David.
A few comments below.
________________________________
From: Brendan Eich <bren...@mozilla.com>
To: David Herman <dher...@mozilla.com>
Cc: Kam Kasravi <kamkasr...@yahoo.com>; P T Withington <p...@pobox.com>;
es-discuss Steen <es-discuss@mozilla.org>
Sent: Sun, May 16, 2010 8:00:35 PM
Subject: Re: modules proposal
On May 16, 2010, at 7:18 PM, David Herman wrote:
>> RegExp literal expressions evaluate to mutable object values, per ES5 and
>> reality (ES3 got this wrong, making an object per literal lexeme -- not per
>> evaluated expression).
>
> Yes, but there's no reason to assume a RegExp token would be a RegExp literal
> expression.
The reader of the source might assume exactly that. One regexp looks like
another, and might be expected to quack like any other.
>> Modules are static. Do we really want to drag in some of the runtime
>> (RegExps) just to filter imports? This seems not only like over-design, but
>> also the wrong design.
>
> Import/export declarations are distinguished contexts; there's no need to
> introduce runtime evaluation. A sensible design for import/export declaration
> with a RegExp would simply be run a regular expression at compile time, with
> no ES object creation involved.
That's possible, and desirable in practice: regexps have effects in real-world
implementations (the unspecified but still used RegExp.$_, RegExp.$1, etc.
properties). If written with /y or /g they mutate there own lastIndex property
and use it for subsequent matches (how many times is /.*\.js$/g evaluated in
that import directive?).
[kam] My use case is the regex would be evaluated server-side with no
client-side eval at runtime or compile time. This pertains more to the dynamic
loader but what I was after was an ability to partially import a module in
those cases where the entire module was not needed.
But in reality, its likely the entire module would be fetched and evaluated. I
do think that module authors would package modules and nested modules in ways
where the server could optimize what was returned to minimize additional trips
if regex's were allowed.
> I'm not advocating the feature, but if we did include it, ISTM the benefit of
> using regexps is precisely their limited power.
You'd have to limit that power from what it is today in terms of effects
(including those pesky de-facto standard effects).
Another unwanted power is that these NFAs misnamed "regular expressions" can
blow up with O(exp(n)) complexity due to backtracking. This is enough of a
problem that we're about to try throwing an exception when JS regexp exec
complexity measured in terms of active backtrack states compared to target
string length seems to be worse than O(n^3) (see
https://bugzilla.mozilla.org/show_bug.cgi?id=452451 and bugs it cites).
Making some tamed, quasi-regexp-just-for-import seemed not what Kam proposed,
but anyway undesirable on its face. I mean, the taming attempt is desirable
ignoring the big picture, but the whole idea seems misbegotten. My two cents.
[kam] An example might be something like SVG.*Filter* where the importer was
interested in retrieving only filter related features within a SVG module.
Brendan's point is valid, if the regex is 'quasi' or treated differently than
true regex expressions
then the use case(s) need to be convincing.
/be
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
