Namespaces as Sugar (was: complexity tax)

[Maciej Stachowiak]

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  
>> reference).
>> 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  
> string.prototype.intrinsic::charAt.

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  
with a working on a high-performance production-quality JavaScript  
implementation. We managed to pretty much rewrite the core interpreter  
for a significant performance boost in about two months, and that was  
struggling against the existing complexity of de facto JavaScript (ES3  
+ 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.

Regards,
Maciej