Namespaces as Sugar (was: complexity tax)
mjs at apple.com
Wed May 28 00:48:30 PDT 2008
On May 27, 2008, at 1:07 PM, Brendan Eich wrote:
> On May 27, 2008, at 11:42 AM, Maciej Stachowiak wrote:
>> On May 27, 2008, at 11:00 AM, Brendan Eich wrote:
>>> What's at issue is whether and why unqualified import matters in
>>> any object, even the global object only, since the NAS proposal
>>> did not allow unqualified import even at global level, and the use-
>>> case for unqualified import was dismissed as not compelling.
>> There's really 4 separable issues:
>> 1) Namespacing of names at global scope (via lexically scoped
>> 2) Unqualified import of names into global scope.
>> 3) Namespacing of arbitrary object properties.
>> 4) Unqualified import of namespaces for arbitrary object properties.
>> I would claim 1 and 2 are essential, 3 can be done by convention in
>> the absence of 4 (a la the NAS proposal) and 4 is unnecessary and
>> harmful to performance.
> Thanks, this is helpful, since the argument you joined was about (2)
> and/or (4) -- there is no unqualified import in the NAS sketch.
> I forgot one of the main use-case for 4, one you've expressed
> interest in already: 'use namespace intrinsic'. Without (4), this
> does not allow early binding for s.charAt(i) given var s:string to
Yeah, but you can't early bind this anyway if s lacks a type
annotation (or you otherwise have inferred that s is of string type).
In fact if you can't infer the type of s then you get worse
performance than if you hadn't opened any namespaces. Plus lookup of
any property names that couldn't have been early bound at all if the
exact type had been inferred is likely to suffer. So I'm not sure any
more it is good to encourage adding "use namespace intrinsic" to
otherwise unchanged ES3 programs.
But you do have my number - I like the potential for early binding
both for program understandability and performance. I would love to
see a way to make it possible without at the same time making property
lookup in the face of unknown types slower. I will think about it
myself but perhaps someone else will come up with something clever.
As for my motherhood & apple pie lecture, it is based on experience
implementation. We managed to pretty much rewrite the core interpreter
for a significant performance boost in about two months, and that was
+ some Mozilla extensions). Along the way we found some correctness
bugs that exist in pretty much all existing implementations
(sequencing considerations in the face of exceptions for instance). If
the language were much more complex, then it would be much harder to
make architectural changes of the implementation. I believe this is a
quality worth preserving. Well-engineered tight code can sometimes
beat the fanciest of rocket science optimizing implementations simply
because it is easier to understand and therefore measure and optimize.
(To some extent, this applies less to pure syntactic sugar that can be
represented in terms of core language constructs, which is why I worry
more about complex semantics.)
> I want to say thanks for making this proposal (open namespace search
> only for lexical references). It leaves most of the use-cases I
> cited intact. Well done, good compromise (not complete evisceration
> of property qualifiers, or dismissal of unqualified import).
Thank you for saying so. I wonder what Mark thinks? (For the record, I
think open namespaces as affecting lexical scope only would also
remove the need for first-class Name objects.)
> The helper/informative usage in the RI does open those namespaces,
> and intrinsic works only as a cross-cutting namespace that can be
> opened via pragma. So we should focus on these, if only to agree to
> disagree on the importance of the former, argue for hardcoding the
> latter via a separate early-binding pragma, and so forth.
I'm not sure there is a good design for an early binding pragma is
that is immune to the performance costs. One possibility I can think
of is to it an error to access a property by an early-bound name on an
object that lacks the early-bound version when the pragma is in effect
(without explicitly qualifying it as not subject to early binding).
That seems potentially icky.
More information about the Es4-discuss