Namespaces as Sugar (was: complexity tax)

[Brendan Eich]

On May 26, 2008, at 6:53 PM, Mark S. Miller wrote:

> On Mon, May 26, 2008 at 2:45 PM, Brendan Eich <brendan at mozilla.org>  
> wrote:
>> In that case, it would still help if you had an argument based on ES4
>> premises that led to a simpler ES4. But it would be sillly to  
>> repeat ES3
>> premises as disqualifying a part of ES4, since they're different  
>> evolutions
>> of ES3 with different design goals based on different premises.
>
> I find this sudden discussion of premises bizarre.

Bizarre or not, it's apparently necessary, since you accused me of  
assuming a conclusion, when I was questioning a premise.  
Demonstrating my counter-claim required some statement of that premise.

I then thought to allow as how it's not shared by ES3.1, but I really  
don't know. ES3.1 has no notion of namespace. This spun-out thread  
"Namespaces as Sugar" might be a proposal aimed at 3.1 that's mean to  
show no need for ES4's namespace semantics, but it does not address  
the "unqualified import" use-case, which requires new semantics in  
ES4 not in ES3 or ES3.1. We need to agree or disagree that this use- 
case matters enough to justify the extra semantics.

I hope it's clear now why I'm breaking down premises, beyond  
demurring from your assertion that I assumed a conclusion. I'm still  
waiting to hear you reject as unnecessary the unqualified import  
facility, which is found in many languages -- and not just in their  
module systems.


> In any case, if
> you'll recall how we got here:

I recall well, but thanks for diagramming most (but not all!) of the  
thread.


> On Mon, May 19, 2008 at 4:32 PM, Douglas Crockford
> <douglas at crockford.com> wrote:
>> These essential features will be added without
>> resorting to new syntax.

Context is missing here. Why? "These" is a pronoun referring not to  
namespaces, but to other features missing from ES3. Here's the  
context you omitted:

Brendan Eich wrote:

> On Mar 26, 2008, at 10:01 AM, Ric Johnson wrote:
>
>
>> Let us take action instead of throwing opinions around:
>> Brendan: What new features that can not be implemented via code
>> constructs now?
>>
>
> This is reductionism, therefore between silly and wrong, but I will  
> list
> a few things:
>
> * you can't make read-only properties in ES3;
>
> *you can't make don't-delete properties of plain old objects (only  
> vars
> in closures);
>
> * you can't make objects that cannot be extended;
>
> * you can't make don't-enum properties in plain old objects;
>

Doug then replied:

> It looks like these omissions will be corrected in ES3.1 by the
> Object.defineProperties function. These essential features will be  
> added without
> resorting to new syntax.


which links up to the first line you quoted in the thread ("These  
essential features ....").

Where in any of this were namespaces and unqualified import  
discussed? Nowhere.

The issues that I argued deserve syntax to be usable may have  
semantics in ES3.1 now, so you can argue (and you have, indeed,  
argued) for desugaring classes or their fixed properties, e.g. (To  
which I counter-argued that desugaring requires a source to source  
compiler like GWT, which not everyone should have to use to get the  
sugar. But that is another thread that died off.)

But nowhere above in my list to which Doug replied are namespaces to  
be found. So new semantics as well as syntax may be needed, depending  
on what use-cases we think are important. And I'm arguing that  
unqualified-import is important.


> If the various camps define incompatible positions as premises, then
> we may as well give up all hope of agreeing on very much.

A premise can be a conclusion from a prior major premise, plus a  
minor premise (or other style of reasoning than syllogistic). I think  
you're mixing up axiom and premise here. Aha!


> But a wise person once said something like
>
>   In mathematics, we justify theorems by derivation from axioms.
>   But as mathematicians, we judge axioms based on what theorems
>   they produce.
>
> (I think it may have been Karl Popper, but I have been unable to find
> anything by searching. Any pointers would be appreciated.)

Hey, I like Popper too -- but our struggle is not a stand-off between  
contradictory axioms, rather it's a search for the axioms (self- 
evident propositions) that are the root premises from which we've  
both reasoned to other premises, and then to conclusions in the form  
of pragmas like "use namespace N".

You switched from "premise" to "axiom" by hauling a Popper quote in,  
but premise != axiom, so we are still not engaging at the level of  
axioms. ES3.1 and ES4 contain conclusions from derived premises that  
are themselves conclusions of prior premises, etc., going back in a  
chain of reasoning to axioms.

That's why I keep raising usability as an issue. Without "unqualified  
import" (Oliver Steele's phrase) or "use namespace N" in ES4 terms,  
experience with other languages leads to the conclusion that  
namespaces that must be explicitly qualified on every use are not  
usable. That's a premise for the further reasoning that has resulted  
in ES4 namespaces, the name lookup algorithm, etc.


> Rather than proceeding from premises, let's continue to argue about
> goals, tradeoffs and taste.

Sorry, those are shifting sands. Let's try to get back toward some  
shared premises, if not toward Mathematical axioms, without dying of  
boredom from all the fine-grained logic chopping. After all, we are  
starting from ES3, and we have lots of experience with programming  
languages in the literature to guide us.

We can appeal to good taste too, but I claim it's much more important  
to pay attention to experience. Let's leave Popper alone and get very  
concrete here. Have you used XML namespaces in compound documents  
with lots of names drawn from two or more vocabularies? It hurts!

/be