Import concerns revisited

[John Reimer]

In article <e8u8ed$1vsl$1 at digitaldaemon.com>, Walter Bright says...
>
>David Medlock wrote:
>> Derek Parnell wrote:
>> 
>>>
>>> I'm hope I'm not messing up Kris' words here but I think he is saying 
>>> that  we need to cut down on the amount of typing and reading people 
>>> *must* do  in a program. Keep it to a minimum. Try and work the syntax 
>>> so that the  common and mandatory things are short, easy, and 
>>> intuitive to do. Make the  unusual and 'special' things have more 
>>> detail in the syntax.
>>>
>> 
>> I 100% agree.  The usual cases should be implicit, and the corner cases 
>> explicit.
>
>But *are* they the usual case? As far as I can tell, Python is the only 
>significant language that allows aliasing of import names (though the 
>Python manual calls it "binding"). (We'll set aside the C++ #define 
>trick as not a reasonable method.) I haven't seen it used in Python 
>code, though I admit I haven't seen much Python code.
>
>That's why I suggest just trying it for a while. Kris' original concerns 
>are met with the combination of 'static import' (I know, I know, should 
>think of some better keyword combination) and 'alias'. Syntax changes 
>should be done conservatively - if there's an existing way to do it, it 
>has to be used a lot to justify special syntax for it.

Walter, we've gone over this several times.  I guess we should keep repeating
ourselves?  "static import" is a weak solution; it's verbose and lacking in
clarity.  If people are to learn D, I think that will be a particularly volatile
area: it needs to be represented in as clear a syntax as possible, especially
since the import/module system will be among the first systems learned by the
new D programmer.  You are clearly a biased party if you think that static
import is an easily understood solution to the problem, and therefore, you
shouldn't be so heavily involved in the decision. ;)

While we understand your desire to keep syntax additions down, there are
situations where being conservative isn't an answer.  If you can find something
equivalent to from/as (which you most certainly haven't), without adopting new
syntax, maybe we'll bite... but so far, I think using 'with' (or from) and 'as'
is an excellent contender.  And no, I don't think we're overburdening D with
this new syntax, since this is such a critical issue.

>Kris brought up 'goto' - sure, we can do a 'while' loop with a goto, but 
>loops are so very, very common that special syntactic sugar for it has 
>proven to be a big win.


I think you are missing the point. *sigh*. Read above. Imports/namespaces make
up what constitutes a D program.  I think it's a very central, critical, and
special to D.


>D already has a lot of syntax in it. We should be very careful about 
>adding more; not every convenience should have its own syntactic sugar.

There are absolutely no worries about being careful, Walter... You've been
extremely careful. Really!  This syntactic sugar, as you call it, cuts down an
whole lot of lines of code in an area and, at the same time, clarifies the whole
action of the namespace domain.  This is no mere syntactic sugar.  Furthermore,
the term "syntactic sugar" is getting rediculously overused lately... what is
syntactic sugar?  What makes something syntactic sugar?  Who decides what is
syntactic sugar?  That's what high level langauges are, in fact: syntactic
sugar.  

What we're talking about is keeping constructs logical, consistant and minimal:
understood.  But that is the whole point of langauge design, is it not? It's too
decide when and where syntactic sugar is appropriate. 

Imports is such a time to make that consideration.

-JJR