ES4 draft: the global object

Jon Zeppieri 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
>  "eval".

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

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
namespace.

-Jon



>
>  --lars
>
>



More information about the Es4-discuss mailing list