ES4 draft: the global object
jaz at bu.edu
Tue Mar 25 15:41:33 PDT 2008
On Tue, Mar 25, 2008 at 5:47 PM, Lars Hansen <lhansen at adobe.com> wrote:
> > Not right in what sense? I'm not sure whether you're
> > claiming that the operator form of intrinsic::eval isn't a
> > namespaced operator (in which case, how is it not a pun?) or
> > that it's not the *only* namespaced operator. (Or maybe you
> > mean something else entirely...)
> I mean that all names are in some namespace, and the name you
> think of as "isNaN" is really "null::isNaN", where null represents
> a "compatibility namespace", to pick something less ambiguous than
All names are in some namespace, yes, but not every identifier (using
the term somewhat loosely) is a name. 'eval' can be a name (i.e., it
can name a function that performs evaluation, or it can name some
other value if it is re-bound), but *qua operator* I don't see how it
could be a name -- unless it's unique among operators. And if it is
unique in this respect, is the benefit worth the inconsistency?
> > Do operator identifiers (like '<') name syntactic bindings?
But 'eval' does/can?
> > Or maybe the term 'operator' is being used equivocally here?
> Operator in the sense that '<' is syntax that causes the language
> implementation to operated upon values, but there is no operator
> overloading and no syntactic bindings for operators at present.
> (They were in for a while, and operators were in the intrinsic
> namespace: intrinsic::=== for example.)
But it sounds to me like the intrinsic::eval operator depends upon the
notion that operators have syntactic bindings. Otherwise, I don't see
what sense it makes to refer to an operator's name. And if that
doesn't make sense, then neither does referring to an operator's
More information about the Es4-discuss