namespaces and expression-qualified names

Jon Zeppieri jaz at bu.edu
Thu Mar 20 22:27:56 PDT 2008


Are namespaces (and I'm not referring to the reflected objects here)
first class values?

The overview document explicitly calls then "compile-time values,"
then proceeds to give the following example:

====
The following lines create namespace constants ns1, ns2, ns3, and ns4;
the first two are anonymous (and equal), the last two have
program-defined content (and are also equal):

    namespace ns1
    namespace ns2 = ns1
    namespace ns3 = "www.ecma-international.org"
    namespace ns4 = "www.ecma-international.org"
====

The example -- specifically, the fact that I can alias a namespace --
suggests that these are first-class, runtime values.

Also, the grammar has an ExpressionQualifiedName non-terminal, which
puts an expression in the namespace position of a lexical reference,
like:

(foo.bar)::x

This, too, suggests that namespaces are first-class values.

On the other hand, the RI only agrees up to a point.  This works:

>> namespace ns1
>> namespace ns2 = ns1
>> ns1::x = 5
5
>> ns2::x
5

This does not:

>> namespace ns1
>> var ns2 = ns1
>> ns1 === ns2
true
>> ns1::x = 5
5
>> ns2::x
**ERROR** VerifyError: namespace expression did not resolve to
namespace fixture (near <no filename>:1:4-1.3)

ns1 and ns2 are identical run-time values, but the latter cannot be
used to qualify x.

Also, I can't seem to find a use of an ExpressionQualifiedName in the
RI that won't result in an error.  (This could just be a bug in the
RI, of course.)  How would an ExpressionQualifiedName be used?


I'm assuming the rationale behind the overview document's position
(that namespaces are compile-time values) is that this is the only way
to make lexical references resolvable at compile-time (ignoring eval
and with for simplicity).  I agree.  But in that case, why have
namespaces mimic first-class values up to a point?  Why allow them on
the right hand side of an assignment expression, at all?  Here is
another example of this kind of odd behavior (and, again, this may
simply be due to bugs in the implementation):

>> namespace ns1
>> ns1::y = 2;
2
>> function test1(x) { print(x); }
>> test1(ns1)
<user "ns1">
>> function test2(x) { print(x::y); }
**ERROR** VerifyError: namespace expression did not resolve to
namespace fixture (near <no filename>:1:28-1.27)

Just to be clear, I'm *not* advocating first-class namespaces.  I'm
just curious why the language seems to pretend that they are
first-class values.

-Jon



More information about the Es4-discuss mailing list