www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Allow identical imports

reply "JS" <js.mdnq gmail.com> writes:
I have ctfe generated code which requires generating import 
statements so symbols can be looked up(avoiding the need to have 
to manually import modules).

1. Allow identical import statements not throw an error.
import std.conv : to;
import std.conv : to;

throws error

Error	1	Error: alias main.to conflicts with alias main.to at 
main.d(5)

such errors make it difficult to write generated code with weak 
state information(since ctfe's can store global state data.

2. Allow if an isImported statement which checks if a symbol is 
imported. This can reduce unnecessary import statements.


I get around 1 by using a table to store the import statements, 
but, again, this only works inside the ctfe call since the table 
can't be global. Multiple code generation in the scope may 
produce the issue.
Jul 30 2013
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
You can use scoped local imports and avoid necessity to track 
global state.
Jul 30 2013
parent reply "JS" <js.mdnq gmail.com> writes:
On Tuesday, 30 July 2013 at 10:36:15 UTC, Dicebot wrote:

 You can use scoped local imports and avoid necessity to track 
 global state.


Huh? If I follow you, this won't work. I'm generating code so 
don't have the luxury to mess with the outer scope where the code 
is going.

mixin(code fragment)

user code

mixin(code fragment)

user code

if both code fragments have the same import statement then there 
is an error. The only way for them to be aware of that is to have 
a global state(well, relative to the scope they are in).
Jul 30 2013
parent reply "Dicebot" <public dicebot.lv> writes:
On Tuesday, 30 July 2013 at 11:01:07 UTC, JS wrote:

 On Tuesday, 30 July 2013 at 10:36:15 UTC, Dicebot wrote:

 You can use scoped local imports and avoid necessity to track 
 global state.


 Huh? If I follow you, this won't work. I'm generating code so 
 don't have the luxury to mess with the outer scope where the 
 code is going.

 mixin(code fragment)

 user code

 mixin(code fragment)

 user code

 if both code fragments have the same import statement then 
 there is an error. The only way for them to be aware of that is 
 to have a global state(well, relative to the scope they are in).


Don't have imports generated in two different mixins in same 
scope. Either move each mixin into own scope, or move import 
generation code into separate mixin that get called once per 
scope. (example of vibe.d using latter: 
https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/http/rest.d#L245)
Jul 30 2013
parent reply "JS" <js.mdnq gmail.com> writes:
On Tuesday, 30 July 2013 at 11:19:37 UTC, Dicebot wrote:

 On Tuesday, 30 July 2013 at 11:01:07 UTC, JS wrote:

 On Tuesday, 30 July 2013 at 10:36:15 UTC, Dicebot wrote:

 You can use scoped local imports and avoid necessity to track 
 global state.


 Huh? If I follow you, this won't work. I'm generating code so 
 don't have the luxury to mess with the outer scope where the 
 code is going.

 mixin(code fragment)

 user code

 mixin(code fragment)

 user code

 if both code fragments have the same import statement then 
 there is an error. The only way for them to be aware of that 
 is to have a global state(well, relative to the scope they are 
 in).


 Don't have imports generated in two different mixins in same 
 scope. Either move each mixin into own scope, or move import 
 generation code into separate mixin that get called once per 
 scope. (example of vibe.d using latter: 
 https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/http/rest.d#L245)


This can't be done. I am using mixins to generate interface code,
class code, etc....

There is only one scope to them. The imports can't be brought out
because they are generated directly from the mixin data passed.

e.g.,

class A
{
     mixin(Property("name", string));
     mixin(Property("x", iObject));
}

iObject potentially requires an import, so I import it... now if
I add


     mixin(Property("y", iObject));

then I'll have two iObjects imported... which will error and
fail, even though there is no big deal about it.
Jul 30 2013
parent "Dicebot" <public dicebot.lv> writes:
On Tuesday, 30 July 2013 at 11:39:59 UTC, JS wrote:

 class A
 {
     mixin(Property("name", string));
     mixin(Property("x", iObject));
 }

 iObject potentially requires an import, so I import it... now if
 I add


     mixin(Property("y", iObject));

 then I'll have two iObjects imported... which will error and
 fail, even though there is no big deal about it.


class A
{
     alias fields = TypeTuple!("name", string, "x", iObject);
     mixin(generateImports!fields);
     mixin(generateProperties!fields);!
}
Jul 30 2013
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
JS:


 I have ctfe generated code which requires generating import 
 statements so symbols can be looked up(avoiding the need to 
 have to manually import modules).

 1. Allow identical import statements not throw an error.
 import std.conv : to;
 import std.conv : to;

 throws error

 Error	1	Error: alias main.to conflicts with alias main.to at 
 main.d(5)

 such errors make it difficult to write generated code with weak 
 state information(since ctfe's can store global state data.


That's untidy. Such things later bite your rump.

Bye,
bearophile
Jul 30 2013
prev sibling parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"JS" <js.mdnq gmail.com> wrote in message 
news:ndlhucgwihfzjsxgihhr forum.dlang.org...

 import std.conv : to;
 import std.conv : to;

 throws error

 Error 1 Error: alias main.to conflicts with alias main.to at main.d(5)


Please file a bug report: http://d.puremagic.com/issues/
Jul 30 2013
parent reply "Dicebot" <public dicebot.lv> writes:
On Tuesday, 30 July 2013 at 12:29:00 UTC, Daniel Murphy wrote:

 Please file a bug report: http://d.puremagic.com/issues/


I don't think it is a bug, enhancement request for error message 
at most.
Jul 30 2013
parent reply Kenji Hara <k.hara.pg gmail.com> writes:
2013/7/30 Dicebot <public dicebot.lv>


 On Tuesday, 30 July 2013 at 12:29:00 UTC, Daniel Murphy wrote:


 Please file a bug report: http://d.puremagic.com/issues/


 I don't think it is a bug, enhancement request for error message at most.


Currently selective import *implicitly* creates alias declaration for each
picked up names, and two equivalent selective import will make two alias
declarations implicitly, then they conflict each other.

import std.conv : to;
import std.conv : to;

is mostly same as:

import std.conv;
alias to = std.conv.to;
alias to = std.conv.to;  // conflict with the first alias

I think it's a not good compiler implementation detail and unnecessary
intrusive behavior.
Now I'm proposing to fix import mechanism in here.
https://github.com/D-Programming-Language/dmd/pull/2256

Kenji Hara
Jul 30 2013
next sibling parent "JS" <js.mdnq gmail.com> writes:
On Tuesday, 30 July 2013 at 14:31:00 UTC, Kenji Hara wrote:

 2013/7/30 Dicebot <public dicebot.lv>


 On Tuesday, 30 July 2013 at 12:29:00 UTC, Daniel Murphy wrote:


 Please file a bug report: http://d.puremagic.com/issues/


 I don't think it is a bug, enhancement request for error 
 message at most.


 Currently selective import *implicitly* creates alias 
 declaration for each
 picked up names, and two equivalent selective import will make 
 two alias
 declarations implicitly, then they conflict each other.

 import std.conv : to;
 import std.conv : to;

 is mostly same as:

 import std.conv;
 alias to = std.conv.to;
 alias to = std.conv.to;  // conflict with the first alias

 I think it's a not good compiler implementation detail and 
 unnecessary
 intrusive behavior.
 Now I'm proposing to fix import mechanism in here.
 https://github.com/D-Programming-Language/dmd/pull/2256

 Kenji Hara


I figured some aliasing was going on underneath(hence the error).

Thanks...
Jul 30 2013
prev sibling next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Tuesday, 30 July 2013 at 14:31:00 UTC, Kenji Hara wrote:

 I think it's a not good compiler implementation detail and 
 unnecessary
 intrusive behavior.
 Now I'm proposing to fix import mechanism in here.
 https://github.com/D-Programming-Language/dmd/pull/2256



That I agree. My comment referred to the opinion that having two 
identical imports in the same scope should not compile anyway, 
whatever the actual reason is.
Jul 30 2013
next sibling parent "Dicebot" <public dicebot.lv> writes:
On Tuesday, 30 July 2013 at 14:42:47 UTC, Dicebot wrote:

 On Tuesday, 30 July 2013 at 14:31:00 UTC, Kenji Hara wrote:

 I think it's a not good compiler implementation detail and 
 unnecessary
 intrusive behavior.
 Now I'm proposing to fix import mechanism in here.
 https://github.com/D-Programming-Language/dmd/pull/2256



 That I agree. My comment referred to the opinion that having 
 two identical imports in the same scope should not compile 
 anyway, whatever the actual reason is.


To clarify even more: I consider it a mistake that identical 
imports are allowed even for "normal" imports but that can't be 
changed. At least specialized ones can be kept clean.
Jul 30 2013
prev sibling next sibling parent reply "Tofu Ninja" <emmons0 purdue.edu> writes:
On Tuesday, 30 July 2013 at 14:42:47 UTC, Dicebot wrote:

 On Tuesday, 30 July 2013 at 14:31:00 UTC, Kenji Hara wrote:

 I think it's a not good compiler implementation detail and 
 unnecessary
 intrusive behavior.
 Now I'm proposing to fix import mechanism in here.
 https://github.com/D-Programming-Language/dmd/pull/2256



 That I agree. My comment referred to the opinion that having 
 two identical imports in the same scope should not compile 
 anyway, whatever the actual reason is.


I would think that a redundant import would be something along 
the lines of a warning, not a full on error, there is no reason 
the compiler shouldn't be able to compile it.
Jul 30 2013
parent reply "Dicebot" <public dicebot.lv> writes:
On Tuesday, 30 July 2013 at 14:52:52 UTC, Tofu Ninja wrote:

 I would think that a redundant import would be something along 
 the lines of a warning, not a full on error, there is no reason 
 the compiler shouldn't be able to compile it.


That is somewhat similar to "statement has no effect" error. Any 
warning that has no valid use case should be an error, it does 
not matter if compiler can do it.
Jul 30 2013
next sibling parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Dicebot" <public dicebot.lv> wrote in message 
news:ghodlivqehfqkvxsisgf forum.dlang.org...

 On Tuesday, 30 July 2013 at 14:52:52 UTC, Tofu Ninja wrote:

 I would think that a redundant import would be something along the lines 
 of a warning, not a full on error, there is no reason the compiler 
 shouldn't be able to compile it.


 That is somewhat similar to "statement has no effect" error. Any warning 
 that has no valid use case should be an error, it does not matter if 
 compiler can do it.


The use case is generated code.  Errors are for things that can cause bugs. 
How can identical imports cause a bug?
Jul 30 2013
prev sibling parent "Tofu Ninja" <emmons0 purdue.edu> writes:
On Tuesday, 30 July 2013 at 15:11:53 UTC, Dicebot wrote:

 On Tuesday, 30 July 2013 at 14:52:52 UTC, Tofu Ninja wrote:

 I would think that a redundant import would be something along 
 the lines of a warning, not a full on error, there is no 
 reason the compiler shouldn't be able to compile it.


 That is somewhat similar to "statement has no effect" error. 
 Any warning that has no valid use case should be an error, it 
 does not matter if compiler can do it.


I think the op is a valid use case, being able to have a mixin 
that imports what it needs regardless if it has been imported 
already or not.
Jul 30 2013
prev sibling parent "Meta" <jared771 gmail.com> writes:
On Tuesday, 30 July 2013 at 14:42:47 UTC, Dicebot wrote:

 That I agree. My comment referred to the opinion that having 
 two identical imports in the same scope should not compile 
 anyway, whatever the actual reason is.


I was positive that it is intended behaviour that multiple 
imports do not cause an error... It says this at 
http://dlang.org/pretod.html#pragmaonce:

"...D does a symbolic include of import files; they only get 
imported once no matter how many times the import declaration 
appears."

Thus, I'd expect "import std.conv: to; import std.conv: to" to 
compile.
Jul 30 2013
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 07/30/2013 04:30 PM, Kenji Hara wrote:

 2013/7/30 Dicebot <public dicebot.lv <mailto:public dicebot.lv>>

     On Tuesday, 30 July 2013 at 12:29:00 UTC, Daniel Murphy wrote:

         Please file a bug report: http://d.puremagic.com/issues/


     I don't think it is a bug, enhancement request for error message at
     most.


 Currently selective import *implicitly* creates alias declaration for
 each picked up names, and two equivalent selective import will make two
 alias declarations implicitly, then they conflict each other.

 import std.conv : to;
 import std.conv : to;

 is mostly same as:

 import std.conv;
 alias to = std.conv.to;
 alias to = std.conv.to;  // conflict with the first alias

 I think it's a not good compiler implementation detail and unnecessary
 intrusive behavior.
 Now I'm proposing to fix import mechanism in here.
 https://github.com/D-Programming-Language/dmd/pull/2256

 Kenji Hara


I think that the two alias declarations should simply not conflict.
Jul 30 2013
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Jul 30, 2013 at 04:58:34PM +0200, Timon Gehr wrote:

 On 07/30/2013 04:30 PM, Kenji Hara wrote:


[...]

Currently selective import *implicitly* creates alias declaration for
each picked up names, and two equivalent selective import will make
two alias declarations implicitly, then they conflict each other.

import std.conv : to;
import std.conv : to;

is mostly same as:

import std.conv;
alias to = std.conv.to;
alias to = std.conv.to;  // conflict with the first alias

I think it's a not good compiler implementation detail and
unnecessary intrusive behavior.
Now I'm proposing to fix import mechanism in here.
https://github.com/D-Programming-Language/dmd/pull/2256

Kenji Hara


 
 I think that the two alias declarations should simply not conflict.


If the two aliases are aliasing the same thing, then they shouldn't
conflict. This should be easy for the compiler to verify, right?


T

-- 
If Java had true garbage collection, most programs would delete themselves upon
execution. -- Robert Sewell
Jul 30 2013