Lucas Goss wrote:
> Regan Heath wrote:
>> Here is my current understanding of the problems and solutions proposed to date. Comments are welcome, including "enough already! the horse is dead!" ;)
>> ...
> 
> Nice! Wiki'd!
> http://www.prowiki.org/wiki4d/wiki.cgi?ImportConflictResolution
> 
> And linked from:
> http://www.prowiki.org/wiki4d/wiki.cgi?ImportIssues
> 
> I added a section for supported solutions so you can put your name by the number you support (makes me feel like I'm signing a declaration of... independence or something, :) ).
> 
> Lucas

I added a Preferred Syntax section too, FWIW.

- Dave

Andrei Khropov wrote:
> Regan Heath wrote:
> 
> <skipped>
> 
> Good survey, thanks. 
> 
> My vote is for #3 as well as #4 to be available (exact syntax may vary).
> 
> ("import std.string std.string" is disgusting :-) )
> 

Yep, I was about to say the same. #3 (FQN import) should be there, regardless of whether #4 (aliasing import, aka prefix import) is or is not as well.

As for #4, (basically the same as kris's RFC), I'm not sure yet, but I guess it would be alright. Altough there is something I think I'm not very found of: the ability for one to change the module and/or package name, like this:
  import foo.string as str;
Instead we could have a syntax that would not allow it (and which would also be shorter, but require a keyword other than import):
  xptoimport foo.string; // makes the name "string" available

This is actually basically the same as the selective import, only that it also allows modules and packages themselves to be selectively imported (which is why it requires a new keyword). (For clarity, it can be called universal selective import)

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

In article <e95lvr$2t28$1@digitaldaemon.com>, Dave says...
>
>Don Clugston wrote:
>> Regan Heath wrote:
>>> Proposed solutions
>>> ------------------
>>> 3:
>>> Prevent import into the "secondary namespace", only allow FQN access.
>>> (AKA "static import")
>>> static import std.string; //exact syntax may vary
>>> static import std.regexp; //exact syntax may vary
>>>
>>> ..find(.. //error
>>> ..std.string.find(.. //ok
>>> ..std.regexp.find(.. //ok
>>>
>>> "All 'static import' does is eliminate the "if the name is not found
>>> in the current module, look in the imports" step. This has the effect of
>>> requiring the use of FQN's when referencing imports."
>>>  - Walter
>>>
>>> 4:
>>> Import into a custom namespace, eg.
>>> import std.string str; //exact syntax may vary
>>> import std.regexp;
>>>
>>> ..str.find(.. //calls std.string.find
>>> ..find(.. //calls std.regexp.find
>>>
>>> This method should also prevent import into the "secondary namespace".
>> 
>> 
>> Thanks, Regan. Indeed this is an attempt at conflict resolution in both meanings. Well done.
>> 
>> Seems to me that one of Walter's key non-negotiables is to ensure that:
>> ------------
>> import std.stdio;
>> 
>> void main()
>> {
>>    writefln("Hello, world!");
>> }
>> ------------
>> still works. Hopefully all of us can see the importance of that.
>> 
>> Personally, I don't have a strong objection to #3, if it was combined with default private imports, we wouldn't have to type "private static import" all the time, which would IMHO be unacceptable.
>> 
>> However, unlike Kris, I don't have any experience with working with really large projects in D (or any language at all, actually) -- so I'll trust Kris on the need for #4.
>> 
>> #4 would definitely need different syntax, with a clearer visual distinction from a traditional import. Whether it be "import alias std.string str;" or "import std.string as str;" or "import std.string = str;" -- I don't have a strong preference. I don't think there would be any need for it to prevent FQN access.
>>
>
>import std.string as string; // Ok, but new keyword

I like this one the best. It is so "readable" while not being too wordy.

>import string = std.string; // Ok: concise, distinct, consistent and logically accurate.

That just looks odd to me... it looks like "import" is some data type, and your assigning some value "std.string" to "string". It also is very different from 'normal' import lines:

import std.string;
import std.string as str;

vs.

import std.string;
import str = std.string;

Putting "as str" at the end of the import is more intuitive than putting a "str =" in the middle of the import line...

disclaimer: add IMHO to all my statements :)

>
>I personally like the last because it's the most visually distinctive (makes it hard to miss the alias) and it represents exactly what is going on, but whatever.
>
>I agree there would be no need to prevent FQN access. So there would be no need to allow 'import std.string = std.string;' to force the FQN to use the original name.
>
>Ergo, the current implementation of alias along with the Walter's 'static import' could be used to implement this type of syntax (internal to the compiler) I believe.
>
>> But really, I'll be happy just as long as we're not left with only #1 and #2. I'm delighted that this fundamental issue is finally getting attention; I'm disappointed at how heated the discussion became.
>> 
>> Thanks again, Regan.

- Jeremy

Jeremy wrote:
> In article <e95lvr$2t28$1@digitaldaemon.com>, Dave says...
>> Don Clugston wrote:
>>> Regan Heath wrote:
>>>> Proposed solutions
>>>> ------------------
>>>> 3:
>>>> Prevent import into the "secondary namespace", only allow FQN access. (AKA "static import")
>>>> static import std.string; //exact syntax may vary
>>>> static import std.regexp; //exact syntax may vary
>>>>
>>>> ..find(.. //error
>>>> ..std.string.find(.. //ok
>>>> ..std.regexp.find(.. //ok
>>>>
>>>> "All 'static import' does is eliminate the "if the name is not found in the current module, look in the imports" step. This has the effect of
>>>> requiring the use of FQN's when referencing imports."
>>>>  - Walter
>>>>
>>>> 4:
>>>> Import into a custom namespace, eg.
>>>> import std.string str; //exact syntax may vary
>>>> import std.regexp;
>>>>
>>>> ..str.find(.. //calls std.string.find
>>>> ..find(.. //calls std.regexp.find
>>>>
>>>> This method should also prevent import into the "secondary namespace".
>>>
>>> Thanks, Regan. Indeed this is an attempt at conflict resolution in both meanings. Well done.
>>>
>>> Seems to me that one of Walter's key non-negotiables is to ensure that:
>>> ------------
>>> import std.stdio;
>>>
>>> void main()
>>> {
>>>    writefln("Hello, world!");
>>> }
>>> ------------
>>> still works. Hopefully all of us can see the importance of that.
>>>
>>> Personally, I don't have a strong objection to #3, if it was combined with default private imports, we wouldn't have to type "private static import" all the time, which would IMHO be unacceptable.
>>>
>>> However, unlike Kris, I don't have any experience with working with really large projects in D (or any language at all, actually) -- so I'll trust Kris on the need for #4.
>>>
>>> #4 would definitely need different syntax, with a clearer visual distinction from a traditional import. Whether it be "import alias std.string str;" or "import std.string as str;" or "import std.string = str;" -- I don't have a strong preference. I don't think there would be any need for it to prevent FQN access.
>>>
>> import std.string as string; // Ok, but new keyword
> 
> I like this one the best. It is so "readable" while not being too wordy.
> 
>> import string = std.string; // Ok: concise, distinct, consistent and logically accurate.
> 
> That just looks odd to me... it looks like "import" is some data type, and your
> assigning some value "std.string" to "string". It also is very different from
> 'normal' import lines:
> 
> import std.string;
> import std.string as str;
> 
> vs.
> 
> import std.string;
> import str = std.string;
> 
> Putting "as str" at the end of the import is more intuitive than putting a "str
> =" in the middle of the import line... 
> 
> disclaimer: add IMHO to all my statements :)
> 

Seems others agree with you - note your preferences here if you want:

http://www.prowiki.org/wiki4d/wiki.cgi?ImportConflictResolution

On Thu, 13 Jul 2006 10:06:25 -0500, Dave <Dave_member@pathlink.com> wrote:
> Lucas Goss wrote:
>> Regan Heath wrote:
>>> Here is my current understanding of the problems and solutions proposed to date. Comments are welcome, including "enough already! the horse is dead!" ;)
>>> ...
>>  Nice! Wiki'd!
>> http://www.prowiki.org/wiki4d/wiki.cgi?ImportConflictResolution
>>  And linked from:
>> http://www.prowiki.org/wiki4d/wiki.cgi?ImportIssues
>>  I added a section for supported solutions so you can put your name by the number you support (makes me feel like I'm signing a declaration of... independence or something, :) ).
>>  Lucas
>
> I added a Preferred Syntax section too, FWIW.

Thanks guys, it looks good.

Regan

In article <optcnfgdgc23k2f5@nrage>, Regan Heath says...
>
>On Thu, 13 Jul 2006 10:06:25 -0500, Dave <Dave_member@pathlink.com> wrote:
>> Lucas Goss wrote:
>>> Regan Heath wrote:
>>>> Here is my current understanding of the problems and solutions
>>>> proposed to date. Comments are welcome, including "enough already! the
>>>> horse is dead!" ;)
>>>> ...
>>>  Nice! Wiki'd!
>>> http://www.prowiki.org/wiki4d/wiki.cgi?ImportConflictResolution
>>>  And linked from:
>>> http://www.prowiki.org/wiki4d/wiki.cgi?ImportIssues
>>>  I added a section for supported solutions so you can put your name by
>>> the number you support (makes me feel like I'm signing a declaration
>>> of... independence or something, :) ).
>>>  Lucas
>>
>> I added a Preferred Syntax section too, FWIW.
>
>Thanks guys, it looks good.
>
>Regan

Doesn't the "import a.b.c : a;" syntax break the context-free parsing thingy? I don't know much about it, but couldn't the colon get confused with the colon in "a = b ? 1 : 2;" stuff?

- jeremy

Jeremy wrote:

> Doesn't the "import a.b.c : a;" syntax break the context-free parsing thingy? I
> don't know much about it, but couldn't the colon get confused with the colon in
> "a = b ? 1 : 2;" stuff?
> 
> - jeremy
> 
> 

Unlikely. The ":" or "as" or whatever is simply /noise/ -- something that is primarily optional for the underlying parser. It does depend on the parser, but DMD is an RD variety so can handle it without issue. In other words, whatever goes in there is not really a keyword in the traditional sense?

Regan Heath wrote:
> Here is my current understanding of the problems and solutions proposed to  date. Comments are welcome, including "enough already! the horse is dead!"  ;)
> 
> Regan
> 
> 
> Import conflict resolution
> --------------------------
> 
> Assumptions
> -----------
> Imports are private by default (Walter seems to like this now?)
> 
> 
> Terminology
> -----------
> FQN = Fully Qualified Name
> 
> 
> Problems
> --------
> A:
> Importing 2 modules with the same symbol causes an immediate collision eg.
> import std.string;
> import std.regexp;
> 
> ..find(.. //error std.string.find or std.regexp.find
> 
> B:
> Changes to a module at a later date may cause a collision at a later date.
> import a;
> import b;
> 
> ..foo(.. //calling a.foo.
> 
> At later date symbol 'foo' is added to b and now the collision occurs.
> 
> 
> Current behaviour
> -----------------
> "How imports work is that first a name is searched for in the current  namespace. If it is not found, then it is looked for in the import list.  If it is
> found uniquely among the imports, then that is used. If it is in more than  one import, an error occurs"
>  - Walter
> 
> "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."
>  - Walter
> 
> 
> Current solutions
> -----------------
> 1:
> import std.string;
> import std.regexp;
> alias std.string.find find;
> 
> ..find(.. //no error std.string.find is called
> 
> 2:
> import std.string;
> import std.regexp;
> 
> ..std.string.find(.. //no error FQN is used
> 
> 
> Opinions/pros/cons on the current solutions
> -------------------------------------------
> 
> 1:
>  - PRO,Solves the import conflict for the intended symbol.
>  - CON,Does NOT solve future symbol conflicts.
>  - CON,The alias is 'physically' seperate from the import.
> 
> 2:
>  - PRO,Solves the import conflict for the intended symbol.
>  - CON,Does NOT solve future symbol conflicts.
>  - CON,Causes more verbose code.
> 
> Neither of these current solutions solves B.
> 
> 
> Proposed solutions
> ------------------
> 3:
> Prevent import into the "secondary namespace", only allow FQN access. (AKA  "static import")
> static import std.string; //exact syntax may vary
> static import std.regexp; //exact syntax may vary
> 
> ..find(.. //error
> ..std.string.find(.. //ok
> ..std.regexp.find(.. //ok
> 
> "All 'static import' does is eliminate the "if the name is not found in  the current module, look in the imports" step. This has the effect of
> requiring the use of FQN's when referencing imports."
>  - Walter
> 
> 4:
> Import into a custom namespace, eg.
> import std.string str; //exact syntax may vary
> import std.regexp;
> 
> ..str.find(.. //calls std.string.find
> ..find(.. //calls std.regexp.find
> 
> This method should also prevent import into the "secondary namespace".
> 
> 5:
> Allow selective import of the exact symbol which is required.
> import std.string.find; //exact syntax may vary
> 
> ..find(.. //calls std.string.find
> 
> No symbols from std.string would be present in the "secondary namespace".
> 
> 
> Opinions/pros/cons on the various solutions
> -------------------------------------------
> 
> 3:
>  - PRO,Solves the import conflict for the intended symbol.
>  - PRO,Solves future symbol conflicts in the same module(s).
>  - CON,Causes more verbose code, using FQN all the time.
> 
> 4:
>  - PRO,Solves the import conflict for the intended symbol.
>  - PRO,Solves future symbol conflicts in the same module(s).
> 
> 5:
>  - PRO,Solves the import conflict for the intended symbol.
>  - CON,Does NOT solve future symbol conflicts.
> 
> 
> Conclusions, extra thoughts
> ---------------------------
> 
> The ideal solution IMO is #4, it solves both A and B in a simple, easy and  elegant(IMO) fashion something that cannot
> be said about the existing solutions #1 and #2.
> 
> To the people who want FQN all the time.. You may view the proposed  solutions #3 and #4 as identical (in value to you).
> The deciding factor to my mind is that other people do not want to use FQN  all the time therefore #4 makes the most
> people happy. The interesting thing, is that FQN can be achieved with  soltion #4, note that:
>   import std.string std.string;
> 
> would be FQN access, without! any further special syntax (like "static"),  to me this makes #4 better than #3
> even if you want to use FQN.
> 
> Yes, it requires more typing but I don't think you can complain about  having to type the module name once more
> when you plan to type it 20+ more times in the course of the file, can you?
> 
> FQN access is curently always present, but not required. However, with  solution #4 FQN access to the symbol is no longer
> ever required. It's presence results in code which can call the same  function in more than one way. This allows the code to
> be inconsistent for no gain (that I can imagine) therefore i think that  solution #4 should prevent FQN access to symbols.

Out of these, I'd want #4 and #5 combined.

Except that I don't understand the following:

> 5:
> Allow selective import of the exact symbol which is required.
> import std.string.find; //exact syntax may vary
>
> ..find(.. //calls std.string.find
>
> No symbols from std.string would be present in the "secondary namespace".
>
>
> Opinions/pros/cons on the various solutions
> -------------------------------------------
>
> 5:
>  - PRO,Solves the import conflict for the intended symbol.
>  - CON,Does NOT solve future symbol conflicts.

It was stated that "No symbols from std.string would be present in the "secondary namespace". Therefore I don't understand the CON argument "Does NOT solve future symbol conflicts".

-----------------

Anyhow, I officially want to

1: be able to import a module into an arbitrary namespace

    import foo.bar.baz.gawk.gasp.stuff as crap;

or even

    import foo.bar.baz.gawk.gasp.stuff as foo.bar.baz.gawk.gasp.stuff;
    // if I so care to choose. ;-/

2: be able to import arbitrary module-top-level-identifiers, without importing the rest of the module

    import da.njet.ruskiij.svesda.myfunc as f;

3: retain compatibility with legacy D code

    import foo.bar;  // All of both go to the "secondary name space",
    import baz.baw;  // as hitherto. (With risk of conflict. :-)  )

1, 2 and 3 should all be usable in the same file!

    import foo.fii.faa;
    import doo.dii.daa.aFunc as df;
    import boo.bii.baa as b;

----

So, Regan, you may count my contribution as you like, here I've just presented what I honestly want, without careful regard [or precise understanding] of the Numbered Categories.


################################

And even here I have to beg, crawl, kiss A, threat, --- or just ask Walter:

   Pretty please, please do include the word "as" in the import statement, please!

I know that it's not needed (i.e., a space would do), I know there are numerous other alternatives ":", "=", you-name-it.

But for the educational motivations you _yourself_ brought up a couple of messages ago, and for corporate code maintenance, or newbie fluency issues (which nobody has yet brought up), please retain the word "as" here.

It really doesn't waste /that/ much of ink.

On Fri, 14 Jul 2006 08:29:59 +0300, Georg Wrede <georg.wrede@nospam.org> wrote:
<snip>
> Out of these, I'd want #4 and #5 combined.
>
> Except that I don't understand the following:
>
>  > 5:
>  > Allow selective import of the exact symbol which is required.
>  > import std.string.find; //exact syntax may vary
>  >
>  > ..find(.. //calls std.string.find
>  >
>  > No symbols from std.string would be present in the "secondary namespace".
>  >
>  >
>  > Opinions/pros/cons on the various solutions
>  > -------------------------------------------
>  >
>  > 5:
>  >  - PRO,Solves the import conflict for the intended symbol.
>  >  - CON,Does NOT solve future symbol conflicts.
>
> It was stated that "No symbols from std.string would be present in the "secondary namespace". Therefore I don't understand the CON argument "Does NOT solve future symbol conflicts".

I guess it can be argued either way. #5 does avoid future symbol collisions (from std.string) but only by virtue of importing no other symbols. In other words the cost of avoiding a collision is not having access to other symbols. So, when you do want more access you have to specify each and every symbol. This solution is too micro-management for my liking.

> -----------------
>
> Anyhow, I officially want to
>
> 1: be able to import a module into an arbitrary namespace
>
>      import foo.bar.baz.gawk.gasp.stuff as crap;

#4

> or even
>
>      import foo.bar.baz.gawk.gasp.stuff as foo.bar.baz.gawk.gasp.stuff;
>      // if I so care to choose. ;-/

#4

> 2: be able to import arbitrary module-top-level-identifiers, without importing the rest of the module
>
>      import da.njet.ruskiij.svesda.myfunc as f;

#5 + #4

> 3: retain compatibility with legacy D code
>
>      import foo.bar;  // All of both go to the "secondary name space",
>      import baz.baw;  // as hitherto. (With risk of conflict. :-)  )

None of the proposals affect the existing import behaviour.

> 1, 2 and 3 should all be usable in the same file!
>
>      import foo.fii.faa;
>      import doo.dii.daa.aFunc as df;
>      import boo.bii.baa as b;

No problem, the proposals are not mutually exclusive.

> So, Regan, you may count my contribution as you like, here I've just presented what I honestly want, without careful regard [or precise understanding] of the Numbered Categories.

You could add your support here:
http://www.prowiki.org/wiki4d/wiki.cgi?ImportConflictResolution
you can even add your own desired syntax.

> ################################
>
> And even here I have to beg, crawl, kiss A, threat, --- or just ask Walter:
>
>     Pretty please, please do include the word "as" in the import statement, please!
>
> I know that it's not needed (i.e., a space would do), I know there are numerous other alternatives ":", "=", you-name-it.
>
> But for the educational motivations you _yourself_ brought up a couple of messages ago, and for corporate code maintenance, or newbie fluency issues (which nobody has yet brought up), please retain the word "as" here.
>
> It really doesn't waste /that/ much of ink.

As Don said and I tend to agree..

"#4 would definitely need different syntax, with a clearer visual distinction from a traditional import. Whether it be "import alias std.string str;" or "import std.string as str;" or "import std.string = str;" -- I don't have a strong preference."
  -Don Clugston

Regan

Regan Heath wrote:
> On Fri, 14 Jul 2006 08:29:59 +0300, Georg Wrede <georg.wrede@nospam.org> wrote:
> <snip>
>> Out of these, I'd want #4 and #5 combined.
>>
>> Except that I don't understand the following:
>>
>>  > 5:
>>  > Allow selective import of the exact symbol which is required.
>>  > import std.string.find; //exact syntax may vary
>>  >
>>  > ..find(.. //calls std.string.find
>>  >
>>  > No symbols from std.string would be present in the "secondary namespace".
>>  >
>>  >
>>  > Opinions/pros/cons on the various solutions
>>  > -------------------------------------------
>>  >
>>  > 5:
>>  >  - PRO,Solves the import conflict for the intended symbol.
>>  >  - CON,Does NOT solve future symbol conflicts.
>>
>> It was stated that "No symbols from std.string would be present in the "secondary namespace". Therefore I don't understand the CON argument "Does NOT solve future symbol conflicts".
> 
> I guess it can be argued either way. #5 does avoid future symbol collisions (from std.string) but only by virtue of importing no other symbols. In other words the cost of avoiding a collision is not having access to other symbols. So, when you do want more access you have to specify each and every symbol. This solution is too micro-management for my liking.
> 

What do you mean "when you do want more access you have to specify each and every symbol"? You mean having to use FQN?


-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D