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


Not true. With the static import + alias you'll have two different ways to refer to the imported symbol(s), and no restriction as to which one is used.

With "as"/"from"/":"/whatever you'll have only 1 way. If you see "bar.foo", there's only 1 thing it can mean.

(With the current import + alias you'll have *3* names for the same thing. I've read somewhere that this is something people generally have problems with, some psychology thing.)

L.

Sean Kelly wrote:
> 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?

A correction to my post: C++ does have namespace-alias-definitions, where a namespace name can be aliased.

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?

You prefer:

	with Foo import bar as abc;

instead of:

	static import Foo;
	alias Foo.bar abc;


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

Import does not import names into the current namespace. It imports them into a secondary namespace, that is looked in *only* if the name isn't found in the current namespace. Alias can then cherry-pick specific symbols out of that secondary namespace and put them in the current namespace, possibly renaming them along the way. (Python's documentation calls that "binding" a name into the local symbol table, but it's the same thing.)

With 'static import', the names aren't even put into the secondary namespace. Unaliased, they can only be accessed as FQN's. An alias can then be used to bind individual symbols into the current namespace.

(*) And yes, you can still access the other names in the static import via FQN's. A couple posters thought that might be a problem, but:
1) I doubt many are going to accidentally type in a FQN;
2) FQN's are not going to produce name collisions unless you happen to name your symbols the same as the topmost package name, which is just not realistically going to be a problem.


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

I did (thanks for the direct link, Sean). The two proposals are semantically identical (*), and I don't see anything in Sean's post to indicate otherwise. It seems to me that Sean agreed that the difference is aesthetic, not functional.

kris wrote:
> Walter Bright wrote:
>> Ivan Senji wrote:
>>
>>> Sure I could use
>>>
>>> static import m2;
>>> alias m2.func f2;
>>>
>>> And that would be an improvement but it is still longer (and arguably
>>> less understandable) than:
>>>
>>> import m2.func as f2; ;) :)
>>
>>
>> Let's say you're going to do more than one:
>>
>> static import m2;
>> alias m2.func f2;
>> alias m2.abcd f3;
>> alias m2.efgh f4;
>>
>> vs:
>>
>> import m2.func as f2;
>> import m2.abcd as f3;
>> import m2.efgh as f4;
>>
>> Not much of a difference. I'm also not understanding why alias is hard to understand.
> 
> 
> You've seen the requested syntax for this option, Walter. Let's revisit it again:
> 
> # with m2 import func, abcd, efgh;

The equivalent would be:

	with m2 import func as f2, abcd as f3, efgh as f4;

Walter Bright wrote:

> Import does not import names into the current namespace. It imports them into a secondary namespace, that is looked in *only* if the name isn't found in the current namespace. Alias can then cherry-pick specific symbols out of that secondary namespace and put them in the current namespace, possibly renaming them along the way.

This is the best explanation of import I've seen so far! It made the current import semantic crystal clear. I suggest to cut-n-past it in the documentation.

---
Paolo

"Walter Bright" <newshound@digitalmars.com> wrote in message news:e8utvp$53$1@digitaldaemon.com...
> 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.
>


The semantics are not exactly the same.  Read Sean and Kris's explanations again, please.  'static import' adds nothing to the what this whole namespace business.  It just sharpens the compiler a bit to enforce FQN for the programmer's sake.  But that is absolutely unnecessary because a D programmer that wants to do that now can just make sure he uses FQNs!  So what's the point of 'static import'?

Also see Lionello Lunesu's post in response to you.


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


I get that you are unconvinced.  In fact, I think it's more than quite apparent!  D is not C, C++, C#, or Ruby.  D is not ADA, Pascal, BCPL, Modula 2, or Simula. Neither is it Python. In fact, D is D.  And we're the D community.  If you want to keep trying to sell D to the C++ community, you've already failed.  The majority of that group will never be convinced as long as they are having their love affair with C++ or are wistfully forseeing an upcoming C++ standard with all the "incredible" features they ever wanted.  Many people choose to be blind because it means inconvenience and turmoil otherwise to see what might be a good for them.

But, for your sake, I hope you realize the community here is your best investment.  Improve D with a conscience for good design, but please stop being ( what appears to be ) double minded about who you are trying to appeal to. Forget the C++ people.  Think of D with wild abandon and commit to making it a true replacement, a bonifide departure from C++.  Yes, absolutely maintain that eye for proven methods, but please don't let that limit your sights if such things don't appear to have been "verified" . No new inventions can succeed while it waits for others to complete the process of collecting the scientific data, of proving it.

What we have asked for here is hardly such a complicated feature that you should be worrying on that level.  It's been demonstrated carefully and methodically how it simplifies the D programmer's life.  Many people, the majority I think, have been supportive of it.  Yet you still appeal to the example of other languages, some that were designed for different audiences.

Finally, the only ones that are interested in learning D are the ones that are fed up with the ugliness and complexity of C++ to such an extent that they decide to see what D is about.  D can certainly start exploring some new territory to prove that there are ways to do things better (and so you have done!).  C++ can never approach that angle because whatever it adds to fix the problems it has, will only make it more complex.

-JJR 

Dave wrote:
> Walter, I think what most are getting at here is that the 'as' syntax just seems cleaner and more efficient from a coding and maintenance POV.
> 
> If it's easy to implement, then I say go for it. If nothing else, people can still use 'explicit' aliasing. I argue that 'as' will actually be quicker for newbies to grasp (*especially* when they see it in example code), and my sense is that it will be a boon to maintenance because it generally won't end-up buried in the middle of a module like many aliases would be. It's not like alias will be a wasted feature - most prominently it will be used for storage types; it just feels more 'natural' that way.

I think you're saying that this is not a discussion about functionality, but about aesthetics. I agree with that.

A couple of people have brought up the alias-in-the-middle thing:

1) If it's in the middle because it's in a nested scope, then it only applies for the duration of that scope. Presumably, it would be easily visible to anyone looking at that scope.

2) I think we can all agree that if it is at module scope in the middle, that is probably bad coding style - especially if there are forward references to it.

3) The with-import-as won't eliminate bad coding style with aliases. One can still plop an alias down in the middle of the module.

4) At least with aliases, they need to be defined within the module. This means one can do a simple search of one source file to find any aliases.

Let's look a bit at the aesthetics:

	with foo.bar import
		abc as def,
		ghi as jkl,
		mno;

	import very.long.name as N;
vs:
	static import foo.bar;
		alias foo.bar.abc def;
		alias foo.bar.ghi jkl;
		alias foo.bar.mno mno;

	import very.long.name;
		alias very.long.name N;


Yes, the latter is more typing. If one was to do this a lot, it can get annoying. But is it going to be done a lot? I think that is the crux of the matter.

P.S. There are other possible syntaxes:

	import foo.bar
	{	def = abc,
		jkl = ghi,
		mno,
	}

In article <e8vife$14p6$1@digitaldaemon.com>, Walter Bright says...

>(*) And yes, you can still access the other names in the static import
>via FQN's. A couple posters thought that might be a problem, but:
>1) I doubt many are going to accidentally type in a FQN;
>2) FQN's are not going to produce name collisions unless you happen to
>name your symbols the same as the topmost package name, which is just
>not realistically going to be a problem.

Does that mean if I do

static import std.string;
alias std.string str;

Then there will trouble if I have a variable named 'std'?

That seems like that could be a source of trouble to me.  But maybe I've misunderstood what you're saying.

Regards,
Bill

Lionello Lunesu wrote:
> Walter Bright wrote:
>> 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.
> 
> 
> Not true. With the static import + alias you'll have two different ways to refer to the imported symbol(s), and no restriction as to which one is used.

True, but I thought that was unimportant. It's not that you're likely to type in very.long.qualified.name by accident.

> With "as"/"from"/":"/whatever you'll have only 1 way.

Not necessarily. Read on...

> If you see "bar.foo", there's only 1 thing it can mean.

That's true regardless of whether there exists a different path to the symbol or not.

Like directory names in a filesystem, there can be an arbitrarily large number of paths to reference symbols at module scope:

--- module A ---
import module B;

--- module B ---
void foo();

--- module C ---
import A;
import B;

B.foo();
A.B.foo();

Bill Baxter wrote:
> 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.)

I thought 'static' would be ideal because it has already had its meaning overloaded into oblivion anyway <g>.

> 2) Regarding ways to avoid new keywords 'as' or 'from'
> 
> '=' is another option for avoiding new 'as'/'from' keywords.

Yes, using symbols is probably better than new keywords.


> 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

Thanks for the reference. Looks like they found that relative imports were a mistake, and want to move to absolute imports. D already uses an absolute import model, so there's no issue there for us.


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

The jargon for that is "context sensitive keywords". They prevent things like a clean lexical pass, mess up syntax highlighters, and generally cause trouble.