Namespaces as Sugar (was: complexity tax)
brendan at mozilla.org
Mon May 26 22:19:05 PDT 2008
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>
>> 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
>> 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
> In any case, if
> you'll recall how we got here:
I recall well, but thanks for diagramming most (but not all!) of the
> 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
> 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
> 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
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!
More information about the Es4-discuss