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 "Dicebot" <public dicebot.lv> writes:
You can use scoped local imports and avoid necessity to track 
global state.
Jul 30 2013
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling 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 next 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
next sibling parent 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
prev 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 next sibling parent "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
prev sibling next sibling parent Kenji Hara <k.hara.pg gmail.com> writes:
--001a11c297deb6b2a104e2bb74cd
Content-Type: text/plain; charset=UTF-8

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 --001a11c297deb6b2a104e2bb74cd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">2013/7/30 Dicebot <span dir=3D"ltr">&lt;<a href=3D"mailto:= public dicebot.lv" target=3D"_blank">public dicebot.lv</a>&gt;</span><br><d= iv class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"gm= ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-l= eft-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> <div class=3D"im">On Tuesday, 30 July 2013 at 12:29:00 UTC, Daniel Murphy w= rote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"> Please file a bug report: <a href=3D"http://d.puremagic.com/issues/" target= =3D"_blank">http://d.puremagic.com/issues/</a><br> </blockquote> <br></div> I don&#39;t think it is a bug, enhancement request for error message at mos= t.<br> </blockquote></div><br></div><div class=3D"gmail_extra">Currently selective= import *implicitly* creates alias declaration for each picked up names, an= d two equivalent selective import will make two alias declarations implicit= ly, then they conflict each other.</div> <div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">import std.= conv : to;</div><div class=3D"gmail_extra">import std.conv : to;</div><div = class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">is mostly same a= s:</div> <div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">import std.= conv;</div><div class=3D"gmail_extra">alias to =3D <a href=3D"http://std.co= nv.to">std.conv.to</a>;</div><div class=3D"gmail_extra">alias to =3D <a hre= f=3D"http://std.conv.to">std.conv.to</a>; =C2=A0// conflict with the first = alias<br> </div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">I thi= nk it&#39;s a not good compiler implementation detail and unnecessary intru= sive behavior.</div><div class=3D"gmail_extra">Now I&#39;m proposing to fix= import mechanism in here.</div> <div class=3D"gmail_extra"><a href=3D"https://github.com/D-Programming-Lang= uage/dmd/pull/2256">https://github.com/D-Programming-Language/dmd/pull/2256= </a><br></div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extr= a">Kenji Hara</div> </div> --001a11c297deb6b2a104e2bb74cd--
Jul 30 2013
prev sibling 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 "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
prev sibling 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 "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
prev sibling next sibling parent "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
prev sibling next 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 next 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 "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