In article <e8unve$2qjl$1@digitaldaemon.com>, Lucas Goss says...

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


No, it's no kludge.  We do it with "private" and "public" already :P, so having a keyword in front of import is a non-issue.  If one really doesn't like it there, they can change the format like much of anything in a structured language.  That's a style issue, not a language one.

Example using selective imports:

# with module1
#      import func1, Struct1, Class1;


See?  Just think of it differently.  In fact that's how I would likely do it to represent the two different sections clearly. Maybe add () to the "with" statement to make it consistent with D's use of "with"?

# with (module1)
#      import func1, Struct1, Class1;

Elegance is not impossible to attain. We just have to be willing to look for it. Consistancy is perfectly attainable too.  We just have to be willing to avoid tunnel vision.


>(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:


Why use '*'?  That unnecessary since the current import already does that.


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


So you don't mind the "static" in front of import?


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


I'm having difficulty following what you are trying to say.

The argument holds very well still because we could make our editors do a whole lot of things, but that doesn't make it right.  We're talking about making a language clear and easy to understand.

-JJR

Dave wrote:
> 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.

Yes, they are ubiquitous. But the renaming of imported symbols? I'm not convinced that is at all ubiquitous, or that it is very desirable in any but unusual cases.


>  > 2) how much power it adds
> 
> It adds the ability to import specific symbols - a quite powerful addition to import I think.

But that power already exists. The discussion is now about whether two statements should be combined into one or not. The power is the same.

Just wanted to join in to make 2 quick comments:

1) regarding "static import foo.bar"

People seem to saying the 'static' is rather meaningless as a word in this context.  But think of it this way:  "static" the English word means "stationary" "showing little changing".  In that sense a static import is an import that doesn't change or move the name of the module being imported. Although you're *importing* it (bringing it into the current namespace), you're not actually *moving* it into the current namespace.  foo.bar.baz remains foo.bar.baz, rather than being moved into the current namespace as baz.  So in that sense, "static" actually seems to make some sense here, I think.  (not saying I like it, though.  "Static" is still overused, and fqn imports should be the default and have the simplest syntax, since they're the safest from a SE standpoint.)

2) Regarding ways to avoid new keywords 'as' or 'from'

'=' is another option for avoiding new 'as'/'from' keywords.

Someone suggetsed
import foo.bar : mybar
I think as an alternative to
import foo.bar as mybar

I kind of like that as a way to avoid introducing a keyword, but maybe '=' would make more sense as in:

import mybar = foo.bar

Or to list a few aliases:

import foo.bar : mybaz = baz, myblip = blip, bork

Or use 'with' in conjuction with '='
with foo.bar import mybaz = baz, myblip = blip, bork

I'm not wild about 'import' getting stuck in the middle there, but it's the same
thing as Python's:
from foo.bar import mybaz as baz, myblip as blip, bork
which most people don't seem to mind.  Using '=' makes it shorter though, and
much shorter than it would be with 'alias' stuck in there somehow.

I think Python's import rules are generally quite sane, and D could do far worse than to copy Python's rules wholesale; however, note that Python 2.5 is getting a new feature related to importing relative to the current module: http://docs.python.org/dev/whatsnew/pep-328.html
--

Actually -- back to the avoiding new keywords discussion -- I'm curious why you can't just introduce 'as' or 'from' as new keywords that are ONLY keywords in an import statement.  Assuming you make the grammatical construct always begin with 'import' the production rules for the grammar should still be simple.

Regards,
'bill the lurker'

Walter Bright wrote:
> Dave wrote:
> 
>> 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.
> 
> Yes, they are ubiquitous. But the renaming of imported symbols? I'm not convinced that is at all ubiquitous, or that it is very desirable in any but unusual cases.

??

I suspect you are very confused about what is actually being asked for. Is that the case? Perhaps you'd like to note what it is that you think is being proposed?


>>  > 2) how much power it adds
>>
>> It adds the ability to import specific symbols - a quite powerful addition to import I think.
> 
> 
> But that power already exists. 

One can import only specific symbols at this time? Really?


> The discussion is now about whether two statements should be combined into one or not. The power is the same.


Again, please refer to Sean's post from yesterday.

John Reimer wrote:
> 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.

I'll repeat myself here, too <g>. The 'static import' combined with 'alias' has

	*exactly the same semantics*

as 'with' 'as'. The only difference between the proposals is if there are two statements or one. There is no difference in power or effect. There is nothing that one can do that the other cannot.


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

I certainly agree with that. What I am unconvinced of, however, is that the *renaming* is central or critical. Note that C, C++, Java, C#, Ruby, etc., do not support renaming. Only Python seems to. And only D has a general purpose renaming capability.

In article <e8usq9$30df$1@digitaldaemon.com>, Walter Bright says...
>
>Dave wrote:
>> 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.
>
>Yes, they are ubiquitous. But the renaming of imported symbols? I'm not convinced that is at all ubiquitous, or that it is very desirable in any but unusual cases.

Renaming imported symbols is pretty common in Python, I think.
from numpy import transpose as T
was one I used myself recently.

Renaming namespaces in python is quite common too.  A lot of numpy users seem to
always start with this:
import numpy as N

Also I seem to be seeing it more in recent C++ programs (aliasing the whole
namespace, anyway, which is all C++ gives you) --
namespace NCF = a_really_long_namespace_called_foo


Also note that the current D import behavior corresponds to this in Python:
from some_module import *
which is something they say you should "avoid whenever *reasonably* possible".

--Bill

Walter Bright wrote:
> 
> I certainly agree with that. What I am unconvinced of, however, is that the *renaming* is central or critical. Note that C, C++, Java, C#, Ruby, etc., do not support renaming. Only Python seems to. And only D has a general purpose renaming capability.

It's a valid point.  However, C++ supports namespaces and 'using' as a means of arbitrarily manipulating scope signifiers and providing short prefixes if the supplied one is too long (though it typically isn't, since C++ does not have a 1-1 mapping between file name/location and FQN).  And C is simply too antiquated/low-level to consider.  I'm not aware of how Java or C# operate in this context however.  I don't suppose anyone with more experience could comment?


Sean

kris wrote:
> Walter Bright wrote:
>> Dave wrote:
>>
>>> 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.
>>
>> Yes, they are ubiquitous. But the renaming of imported symbols? I'm not convinced that is at all ubiquitous, or that it is very desirable in any but unusual cases.
> 
> ??
> 
> I suspect you are very confused about what is actually being asked for. Is that the case? Perhaps you'd like to note what it is that you think is being proposed?

I'm beginning to feel like the focus is slipping a bit as well. However, the current issue of contention seems to be whether or not aliasing package/module names to something a bit more concise will be a common practice.  I assert that it will be, particularly if D gets something akin to "static import" where names must be fully-qualified. But the only crystal ball I can offer are the few nontrivial libraries that have been written for D (such as Mango) combined with experience and a general sense of how I expect to do things in the future.

>> The discussion is now about whether two statements should be combined into one or not. The power is the same.
> 
> Again, please refer to Sean's post from yesterday.

As this thread has become quite extensive, I believe this is the post Kris is referring to:

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


Sean

kris wrote:
> 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;

I know. The ':' isn't even necessary.

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

The idea with regex came from Matthew's comments that when he wanted to do regex, he went with Ruby. Ruby and Perl have regex front and center, and they are heavily used in those languages. So, the fact that they are lightly used in D may be caused by them being *difficult to use* in D rather than because there is no interest in regex.

So I wanted to see why regex was so convenient in Ruby, and if that convenience could be migrated to D, thereby making D suitable for applications that did make heavy use of regex. Sort of "build it and see if they come", if you may.

Import is used everywhere. No argument there. But is selective import? Import with renaming? That is far less clear. If the latter capabilities are critical and would be ubiquitously used, why aren't they in C, C++, Java, Ruby or C#? They are in Python - but are they ubiquitously used in Python?

(On a personal style note, I wouldn't want to rename imports, especially if a lot of programmers are working on the project. I'd rather use FQN's so when I see foo.bar.abc, I know we're talking about the same thing.)

And I want to add once again, that we are not talking about a difference in power or capability. Just whether it is two statements, one of which uses existing D capabilities, or a sprinkle of syntactic sugar to combine them into one statement.

And lastly, to reiterate, it is not about how often import is used. It is how often selective import, or import with renaming, is likely to be used.

Walter Bright wrote:
> Dave wrote:
>> 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.
>
> Yes, they are ubiquitous. But the renaming of imported symbols? I'm not convinced that is at all ubiquitous, or that it is very desirable in any but unusual cases.

Because when libs. and the projects that use them get bigger it will probably get much more desirable, and not for just unusual cases.

For example, you can/have to use FQN in C# w/o an 'import', but through the 'using' directive can abandon the FQN:

System.Data.OleDb.OleDbCommand cmd = new System.Data.OleDb.OleDbCommand(...);

or

using System.Data.OleDb;
...
OleDbCommand cmd = new OleDbCommand(...);

and then:

using olecmd = System.Data.OleDb.OleDbCommand;
using odbcmd = System.Data.Odbc.OdbcCommand;
...
olecmd ocmd = new olecmd();
...
odbcmd dcmd = new odbcmd();

the last form is like the from / as syntax.

I like it - it can *really* cut down on the amount of superfluous code you have to write / scan / read for things like OleDbCommand, which are often used all over the place in a C# 'module'.

Because of the size of the .NET library, namespaces like 'System.Data.OleDb' (or worse) are very uncommon.

>
>>  > 2) how much power it adds
>>
>> It adds the ability to import specific symbols - a quite powerful addition to import I think.
>
> But that power already exists. The discussion is now about whether two statements should be combined into one or not. The power is the same.

Yes but the proposed syntax also allows things like this:

import from a.very.popular.db.lib open as dbopen, close as dbclose;

rather than

import a.very.popular.db.lib;
alias a.very.popular.db.lib dblib;
alias dblib.open dbopen;
alias dblib.close dbclose;

Actually I think there is another criteria: 7) Does a feature build-in something useful or more convenient for large scale development that C and C++ don't have, or more importantly, Java and C# _do_ have.

The 'from' / 'as' syntax does that as well, again IMHO.

Walter, only you know how tough it is to implement. If it would be a total PITA to implement over 'static import' than I completely understand, especially at this stage.

- Dave