Walter Bright wrote:
> 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.
> 
> 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'm not sure what exactly Kris said, but imports are ubiquitous. Not used as much as loops of course, but they are used in every program.

The goto also kind of equates with 'alias' in that goto's and alias's will be stuck almost anywhere in the code while (by convention) imports are at top. So there's an encouragment of good coding practices and maintenance element to this too.

> 
> 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.

I agree, but this will be a major convenience, imho.

The proposal here

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/39967
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/39973

seems to meet this criteria:

a) address all of Kris' concerns (if not Kris, pipe in here).
b) backward compatible.
c) can be implemented w/o significanly changing the current compiler (I think) other than for the import statement additions.
d) is consistent with how import + alias works now.
e) are a significant convenience.
f) keep the visual continuity of import statements for maintenance purposes.
g) encourage good coding practices with regards to imports and aliasing.

- Dave

Please, no new keywords!

We can't solve this namespace polution by adding another keyword... Especially a short one.

My vote goes to:  import some.mod alias mymod;

No new keyword; existing keyword used with similar function, but different context, so should parse just fine.

My 2c.

L.

Dave wrote:
> g) encourage good coding practices with regards to imports and aliasing.
> 

In the long run, this may be "listed last but certainly not least". Debugging other people's code will be hard enough without having to grep for imported symbol aliases everywhere.

Dave wrote:
> Walter Bright wrote:
>>
>> 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.
>
> I agree, but this will be a major convenience, imho.
>
> The proposal here
>
> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/39967
> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/39973
>
> seems to meet this criteria:
>
> a) address all of Kris' concerns (if not Kris, pipe in here).
> b) backward compatible.
> c) can be implemented w/o significanly changing the current compiler (I think) other than for the import statement additions.
> d) is consistent with how import + alias works now.
> e) are a significant convenience.
> f) keep the visual continuity of import statements for maintenance purposes.
> g) encourage good coding practices with regards to imports and aliasing.
>
> - Dave

Taking Walter's criteria from Lionello's post:

> Each idea goes through a gauntlet of:
> 1) is lack of this idea turning users away from D

Right now, I don't know. Based on the response of several long-time users and many in this newsgroup, it probably will once more complex projects are attempted, especially libraries.

> 2) how much power it adds

It adds the ability to import specific symbols - a quite powerful addition to import I think.

> 3) how much complexity it adds

Not a lot for the programmer. It could actually remove a large amount of complexity for large projects. It doesn't change how import or alias work now so it doesn't add any complexity if not used.

> 4) is it consistent with the rest of D

Yes.

> 5) how hard is it to implement

It combines the current import and alias with what you already have in mind for 'static import'.

> 6) how does it rank in importance against all the other ideas

From the response over this weekend, I'd say "NEAR THE TOP".

Walter Bright wrote:
> 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.

Yes, most of us are sensitive to that also. But it needs to be traded off carefully against usage patterns. I suggest you take a look at Sean's extensive and carefully considered reponse from yesterday, and perhaps mine also, since you appear to have ignored everything stated in both judging by the above comment?

BTW: it's perfectly feasible to handle all requirements with no new keywords at all:

import lib.text.locale;

import lib.text.locale : locale;

import lib.text.locale.Date;

import lib.text.locale.Date : myDate;


> 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.

This comes across as thoroughly disingeneous. If you want a comparison, Walter, use your own comparison with the built-in regex?

As was pointed out, Regex is /very/ rarely used in the grand scheme of things. Whereas import is used multiple times in pretty much every single module. It would be a mildly positive sign if you'd at least acknowledge that fact?

I again implore you to revisit those posts, and the followup ones posted by Dave and the many others.


> 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.


Recall the following:

1) the concept of modules and the usage thereof is considered a principal aspect of D, and

2) import is something used *several times* in pretty much every D module

Thus, the earlier question remains: Do you, or do you not, wish the safe approach for import to be easy and convenient to use, maintain, and understand at a glance?

In article <e8u8ed$1vsl$1@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

Walter Bright wrote:
> 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.

Hmm... then how did we ever get MatchExpressions ? Or the new delegate literal syntax ? It seems like it requires an army to convince you about new adding features even if they are as obvious as the extra arguments to assert.

We should be careful about adding more syntax, but we shouldn't be paranoid about it. I don't want to sound rude, but you seem to be totally ignoring all the fine points that long time D users have stated in the recent discussions. What is so terrible about adding more convenient ways to import modules, especially if they can ease project maintenance and increase code readability ? Sure, you have your 'static' import. There are a few problems with it though. First, probably least important aspect is its name. What does 'static' mean here ? The reluctance to make it any better ? *g*

Secondly, let's examine a sample usage of the proposed syntax:

with foo.bar.baz import a, b, c, d, e, f;


Using static import, it becomes:

static import foo.bar.baz;
alias foo.bar.baz.a a;
alias foo.bar.baz.b b;
alias foo.bar.baz.c c;
alias foo.bar.baz.d d;
alias foo.bar.baz.e e;
alias foo.bar.baz.f f;


You might consider it as 'not that bad'. But think about refactoring. Say, you need to change the module 'foo.bar.baz' to 'foo.x.y'. With the proposed syntax, you just do one simple change. With 'static import', well... many.
Another downside is that, the selective import using the 'with' construct only imports these symbols into the current scope, while 'static import' allows you to access all symbols from the imported module if you use a fully qualified name. This is as evil as the "'private', yet not private" symbols in modules.

You want to give 'static import' a try and see how it turns out ? Why don't you implement the proposal instead, call it 'DMD.experimental.163' and see if *this one* works or not ?


-- 
Tomasz Stachowiak  /+ a.k.a. h3r3tic +/

Tom S wrote:

> Another downside is that, the selective import using the 'with' construct only imports these symbols into the current scope, while 'static import' allows you to access all symbols from the imported module if you use a fully qualified name. This is as evil as the "'private', yet not private" symbols in modules.

While I support improving import (particularly allowing import of single symbols), I think you're exaggerating here. There is actually nothing wrong if all FQNs from a module are accessible (if private worked, anyway ;), as most all of the problems arise only with unqualified names.. In fact, some languages (e.g. Java) allow access via FQN without even specifically importing anything, and I never heard referred to that feature as evil before :)

That private symbols are visible is pure evil, though :) They should behave as if they don't exist to outside their module, that being the whole point of tagging something as private.


xs0

xs0 wrote:
> Tom S wrote:
> 
>> Another downside is that, the selective import using the 'with' construct only imports these symbols into the current scope, while 'static import' allows you to access all symbols from the imported module if you use a fully qualified name. This is as evil as the "'private', yet not private" symbols in modules.
> 
> While I support improving import (particularly allowing import of single symbols), I think you're exaggerating here. There is actually nothing wrong if all FQNs from a module are accessible (if private worked, anyway ;), as most all of the problems arise only with unqualified names.. In fact, some languages (e.g. Java) allow access via FQN without even specifically importing anything, and I never heard referred to that feature as evil before :)

Actually, i just wish D imports worked like in Python. Then

import foo.bar.baz;
foo.bar.baz.a = 1;

would be legal, while

from foo.bar.baz import b;
foo.bar.baz.a = 1;

would be illegal. As I see it, one of the points about using selective imports is the ability to specify *exactly* what should be imported and no more. I wouldn't like to get access to the whole module thru FQNs just because I wanted a few symbols and were forced to use 'static import'.


-- 
Tomasz Stachowiak  /+ a.k.a. h3r3tic +/

Walter Bright wrote:
> 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.
> 
> 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.
> 
> 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.

I can see your concerns and after trying out some ideas I partly agree.

I just wish I knew who broke the dam because I don't like this water under the bridge. Having the FQN as default seems to be the best solution as any keyword before import seems like a kludge. And I think this syntax would be nice:

(1)
import std.math.*;
import std.stdio.writefln;
import std.stdio.writef;

While the list style is nice in that it's a little less typing, and the static is somewhat nice in that it doesn't break existing things:

(2)
static import math;
import std.stdio : writefln, writef;

The argument that a rename of the base library (in this case std.stdio) would be a pain to update I don't think holds. A rename is a simple find and replace, which most text editors do simply. The vertical layout of the first for me is easier (in my opinion) to read, and anything before import makes the statement more confusing (as in the static).

But I definitely agree about the private issue. Visible private modules are evil. So if you find out why private is like it is in C++, please let us know so we can fix those issues that cause private to be broken before more dams break and water seeps under the bridge.

Lucas