Bruno Medeiros wrote:
> 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?

When selectively importing you only have access to the symbols that are listed in the import statement - not. If you want to import yet another symbol, you have to explicitly add it to the imports - every time. But when using #4, new accessible symbols are automagically imported to a secondary namespace).

-- 
Jari-Matti

Hey Kris and Jeremy,

Kris: You are correct that this construct will not have much of an effect on the dmd frontend, as far a parsing goes (semantically, it shouldn't be a big issue either, I believe). As far as the ":" or "as" keywords being \noise\, they are actually TERMINALS in my grammar and thus can be "ignored" if there is anther rule that matches the input without said terminals. ie:

nonterm(Decl*) ImportDeclaration {
-> IMPORT x:ImportNames SEMI
-> IMPORT x:ImportNames COLON Identifier SEMI
}

The rules above (the example is in my parser - using Elkhound syntax) show that we can easily match an "ImportDeclaration" using either "import x.y;" or "import x.y : something;"

The terminal ":" is a keyword that already exists in the lexer. The terminal "as" would still be a keyword "in the traditional sense", if used, and would need to be added to the lexer. It would not be a big deal to add to my lexer or parser, however.


I assume what Jeremy means by the "context-free" thingy is actually a concern with added ambiguities or conflicts. My parser doesn't have any extra ambiguities when adding the ":" or "as" keyword to the ImportDeclaration rule of the parser. There are no extra conflicts (shift/reduce or reduce/reduce for the parser guys) added by this new rule, either.

If anyone has any other syntactic additions that they would like to test, I can easily add them to my parser to check for conflicts/ambiguities. The semantics will have to be checked by Walter in his frontend. If I find some time soon, I will try to get my parser code into shape (and upgrade to version 0.162) for release on dsource.org, so that others can test out new syntax ideas, as well. Semantic checking may come when version 1.0 is available.

Thanks,
K.Wilson

P.S. Hey Jeremy...D is not without ambiguities in the (0.149) spec/version that I worked off of. There are several ambiguities that the dmd frontend deals with (and Walter has discussed before, I believe). I have about 4 ambiguities in my grammar. I also have a lot of conflicts which are dealt with using default conflict resolution schemes at the moment (semantic checking, when added, would deal with some of these conflicts differently).


In article <e96khi$aql$1@digitaldaemon.com>, kris says...
>
>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?

Jari-Matti Mäkelä wrote:
> Bruno Medeiros wrote:
>> 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?
> 
> When selectively importing you only have access to the symbols that are
> listed in the import statement - not. If you want to import yet another
> symbol, you have to explicitly add it to the imports - every time. But
> when using #4, new accessible symbols are automagically imported to a
> secondary namespace).
> 

I didn't understand that "- not." in the first statement. I'm assuming it wasn't supposed to be there.

So, yes, with selective import you only have access to the symbols that are listed in the import, but that is the same as #4's aliasing import:
  import std.string str; //exact syntax may vary
Here only the name 'str' is imported, if you want to import another symbol, you also have to add another import. Isn't that so?

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

On Sat, 15 Jul 2006 10:59:13 +0100, Bruno Medeiros <brunodomedeirosATgmail@SPAM.com> wrote:
> Jari-Matti Mäkelä wrote:
>> Bruno Medeiros wrote:
>>> 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?
>>  When selectively importing you only have access to the symbols that are
>> listed in the import statement - not. If you want to import yet another
>> symbol, you have to explicitly add it to the imports - every time. But
>> when using #4, new accessible symbols are automagically imported to a
>> secondary namespace).
>>
>
> I didn't understand that "- not." in the first statement. I'm assuming it wasn't supposed to be there.
>
> So, yes, with selective import you only have access to the symbols that are listed in the import, but that is the same as #4's aliasing import:
>    import std.string str; //exact syntax may vary
> Here only the name 'str' is imported, if you want to import another symbol, you also have to add another import. Isn't that so?

No. #4 "import std.string str;" imports _all_ the symbols from std.string into a namespace/prefix called "str". So, the difference is this:

import std.string str;
str.find();    // ok, calls std.string.find
str.tolower(); // ok, calls std.string.tolower

import std.string.find;
find();    // ok, calls std.string.find
tolower(); // error, std.string.tolower has not been imported.

Regan

In article <e9ae71$d4j$1@digitaldaemon.com>, Bruno Medeiros says...
>
>Jari-Matti Mäkelä wrote:
>> Bruno Medeiros wrote:
>>> 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?
>> 
>> When selectively importing you only have access to the symbols that are listed in the import statement - not. If you want to import yet another symbol, you have to explicitly add it to the imports - every time. But when using #4, new accessible symbols are automagically imported to a secondary namespace).
>> 
>
>I didn't understand that "- not." in the first statement. I'm assuming it wasn't supposed to be there.
>
>So, yes, with selective import you only have access to the symbols that are listed in the import, but that is the same as #4's aliasing import:
>   import std.string str; //exact syntax may vary
>Here only the name 'str' is imported, if you want to import another symbol, you also have to add another import. Isn't that so?
>

No! In selectively importing std.string.find you are only importing the find()
method from the module std.string. This allows you access to std.string.find()
but nothing else from that module.

| import std.string.find;
|
| void main()
| {
|   char[] s = "Something to find";
|   find(s, "to"); // Ok
|   std.string.find(s, "find"); // Ok?
|   char[][] words;
|   words = std.string.split(s); // Illegal
| }

With option #4 you are importing the entire std.string module into a namespace called "str" (or whatever else you'd like) and you have complete access to the symbols from that module through str.

| import std.string as str;
|
| void main()
| {
|   char[] s = "Something to find";
|   find(s, "to"); // Illegal
|   str.find(s, "to"); // Ok
|   std.string.find(s, "find"); // Illegal
|   str.find(s, "find"); // Ok
|   char[][] words;
|   wirds = split(s); // Illegal
|   words = std.string.split(s); // Illegal
|   words = str.split(s); // Ok
| }

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

Andrew Edwards

Bruno Medeiros wrote:
> Jari-Matti Mäkelä wrote:
>> Bruno Medeiros wrote:
>>> 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?
>>
>> When selectively importing you only have access to the symbols that are listed in the import statement - not. If you want to import yet another symbol, you have to explicitly add it to the imports - every time. But when using #4, new accessible symbols are automagically imported to a secondary namespace).
>>
> 
> I didn't understand that "- not." in the first statement. I'm assuming it wasn't supposed to be there.

No. I was in a bit hurry and forgot that. I wanted to say that it does not import the whole module.

Regan Heath wrote:
> On Sat, 15 Jul 2006 10:59:13 +0100, Bruno Medeiros <brunodomedeirosATgmail@SPAM.com> wrote:
>> Jari-Matti Mäkelä wrote:
>>> Bruno Medeiros wrote:
>>>> 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?
>>>  When selectively importing you only have access to the symbols that are
>>> listed in the import statement - not. If you want to import yet another
>>> symbol, you have to explicitly add it to the imports - every time. But
>>> when using #4, new accessible symbols are automagically imported to a
>>> secondary namespace).
>>>
>>
>> I didn't understand that "- not." in the first statement. I'm assuming it wasn't supposed to be there.
>>
>> So, yes, with selective import you only have access to the symbols that are listed in the import, but that is the same as #4's aliasing import:
>>    import std.string str; //exact syntax may vary
>> Here only the name 'str' is imported, if you want to import another symbol, you also have to add another import. Isn't that so?
> 
> No. #4 "import std.string str;" imports _all_ the symbols from std.string into a namespace/prefix called "str". So, the difference is this:

Which is the same to say that it imports the 'str' symbol (which is 'std.string') into the current namespace.

> 
> import std.string str;
> str.find();    // ok, calls std.string.find
> str.tolower(); // ok, calls std.string.tolower
> 
> import std.string.find;
> find();    // ok, calls std.string.find
> tolower(); // error, std.string.tolower has not been imported.
> 
> Regan
> 

But I get your point. (did you see my comment about the universal selective import?)

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

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

I'm updating the Wiki then. The CON for #5 is not that it "Does NOT solve future symbol conflicts." but rather that is it very verbose when importing many symbols from the same module.

I've also added my proposal of a universal selective import.

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

On Sat, 15 Jul 2006 12:43:16 +0100, Bruno Medeiros <brunodomedeirosATgmail@SPAM.com> wrote:
> Regan Heath wrote:
>> On Sat, 15 Jul 2006 10:59:13 +0100, Bruno Medeiros <brunodomedeirosATgmail@SPAM.com> wrote:
>>> Jari-Matti Mäkelä wrote:
>>>> Bruno Medeiros wrote:
>>>>> 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?
>>>>  When selectively importing you only have access to the symbols that are
>>>> listed in the import statement - not. If you want to import yet another
>>>> symbol, you have to explicitly add it to the imports - every time. But
>>>> when using #4, new accessible symbols are automagically imported to a
>>>> secondary namespace).
>>>>
>>>
>>> I didn't understand that "- not." in the first statement. I'm assuming it wasn't supposed to be there.
>>>
>>> So, yes, with selective import you only have access to the symbols that are listed in the import, but that is the same as #4's aliasing import:
>>>    import std.string str; //exact syntax may vary
>>> Here only the name 'str' is imported, if you want to import another symbol, you also have to add another import. Isn't that so?
>>  No. #4 "import std.string str;" imports _all_ the symbols from std.string into a namespace/prefix called "str". So, the difference is this:
>
> Which is the same to say that it imports the 'str' symbol (which is 'std.string') into the current namespace.

Yes, I guess you could say that.. tho I don't really think of 'str' as being a symbol so much as an alias (another name) for a package/module. Would you call a package/module a symbol? I guess you could.

>>  import std.string str;
>> str.find();    // ok, calls std.string.find
>> str.tolower(); // ok, calls std.string.tolower
>>  import std.string.find;
>> find();    // ok, calls std.string.find
>> tolower(); // error, std.string.tolower has not been imported.
>>  Regan
>>
>
> But I get your point. (did you see my comment about the universal selective import?)

Yes. I personally prefer the more explicit nature of #4, eg. "import std.string as string" mentions both "std.string" and "string" in the statement. "SELECTIVEIMPORT std.string" mentions only "std.string" but not (explicitly) "string". I think #4 is more obvious to the newcomer or the casual observer and the cost of typing a few more letters in one place.

Regan