www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - importing modules with non-identifier names

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Has anyone been irked by this? If you have a module called 5th-element.d 
there is no way to import that. I don't think it's a major issue, but 
I'm also seeing it as a limitation that should have a better explanation.

One way to circumvent that may be

import fifth = "5th-element.d";

i.e., specify the file as a string and assign to it a regular D 
identifier. Probably similar things have been discussed in the past, 
what's the general impression?


Andrei
Oct 31 2009
next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sat, Oct 31, 2009 at 12:21:31PM -0500, Andrei Alexandrescu wrote:

 Has anyone been irked by this? 


Yes, quite a bit. I tend to use names-like-this whenever I'm allowed,
which includes the filesystem. Of course, it is easy enough to rename
the file when doing D.


 One way to circumvent that may be
 
 import fifth = "5th-element.d";
 
 i.e., specify the file as a string and assign to it a regular D 
 identifier. Probably similar things have been discussed in the past, 
 what's the general impression?


I could live with that, but it doesn't seem to work with folders. Let's say
I had one called "game-api" with a file inside named "main.d".

Would you do something like this:

import gameapi.main = "game-api/main.d";

How would that work with the include path?

What about:

import whatever = "../folder/file.d";

If that was allowed, I'd expect imports to turn into a bit of a mess. Instead
of bugging with the -I, you'd just = ".../..." most everything.

Then, what about .di files?




While I'm irked by the dash import not working, I think the fix here would
have more weird corner cases to deal with than is worth it. It is easier to
just keep it how it is.


 
 
 Andrei


-- 
Adam D. Ruppe
http://arsdnet.net
Oct 31 2009
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:


 Has anyone been irked by this? If you have a module called 5th-element.d 
 there is no way to import that. I don't think it's a major issue, but 
 I'm also seeing it as a limitation that should have a better explanation.


It's a small limitation, but in practice I don't think it will cause
significant problems. And it can be seen as a way to keep module names cleaner.
The module system has way larger problems that need to be fixed first.

I may even like to further restrict identifiers allowed as module names: only
ones that start with a lowercase. This enforces an already existing style guide
of D, see "Naming Conventions: Module":
http://www.digitalmars.com/d/2.0/dstyle.html

Bye,
bearophile
Oct 31 2009
prev sibling next sibling parent reply Don <nospam nospam.com> writes:
Andrei Alexandrescu wrote:

 Has anyone been irked by this? If you have a module called 5th-element.d 
 there is no way to import that. I don't think it's a major issue, but 
 I'm also seeing it as a limitation that should have a better explanation.
 
 One way to circumvent that may be
 
 import fifth = "5th-element.d";
 
 i.e., specify the file as a string and assign to it a regular D 
 identifier. Probably similar things have been discussed in the past, 
 what's the general impression?


It's just one of a great many cases which would be fixed by introducing 
__identifier("XXX"). (That's also a construct which would do wonders for 
string mixins, BTW).
Oct 31 2009
parent Yigal Chripun <yigal100 gmail.com> writes:
On 31/10/2009 20:58, Don wrote:

 Andrei Alexandrescu wrote:

 Has anyone been irked by this? If you have a module called
 5th-element.d there is no way to import that. I don't think it's a
 major issue, but I'm also seeing it as a limitation that should have a
 better explanation.

 One way to circumvent that may be

 import fifth = "5th-element.d";

 i.e., specify the file as a string and assign to it a regular D
 identifier. Probably similar things have been discussed in the past,
 what's the general impression?


 It's just one of a great many cases which would be fixed by introducing
 __identifier("XXX"). (That's also a construct which would do wonders for
 string mixins, BTW).


This could be done by adding a Symbol type a-la Ruby:

auto fifth = new Symbol("5th-element.d");
import fifth;

Symbol could also contain logic for handling [de]mangling of symbols:

void foo();
auto str = foo.toSymbol.mangled();

this can simplify the language/compiler. all the logic for handling 
alias would be moved into this type, for example, alias template 
parameters would be typed as Symbols:

template foo(int i, Symbol s) { ... }
Oct 31 2009
prev sibling next sibling parent reply Yigal Chripun <yigal100 gmail.com> writes:
On 31/10/2009 19:21, Andrei Alexandrescu wrote:

 Has anyone been irked by this? If you have a module called 5th-element.d
 there is no way to import that. I don't think it's a major issue, but
 I'm also seeing it as a limitation that should have a better explanation.

 One way to circumvent that may be

 import fifth = "5th-element.d";

 i.e., specify the file as a string and assign to it a regular D
 identifier. Probably similar things have been discussed in the past,
 what's the general impression?


 Andrei


IMO physical storage should be orthogonal to logical structure of the 

what namespace(s) it contains so the compiler can figure out what 
assembly to use when you use a namespace.
I might want to store a single namespace/package in multiple folders, 
for example to separate the implementation into /win32 /linux etc...

The downside to this is that it's a little more complicated.
The tool chain should also provide a reverse lookup from a 
symbol/namespace to any assemblies that contain it, probably a compiler 
flag.
Oct 31 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Yigal Chripun wrote:

 On 31/10/2009 19:21, Andrei Alexandrescu wrote:

 Has anyone been irked by this? If you have a module called 5th-element.d
 there is no way to import that. I don't think it's a major issue, but
 I'm also seeing it as a limitation that should have a better explanation.

 One way to circumvent that may be

 import fifth = "5th-element.d";

 i.e., specify the file as a string and assign to it a regular D
 identifier. Probably similar things have been discussed in the past,
 what's the general impression?


 Andrei


 
 IMO physical storage should be orthogonal to logical structure of the 

 what namespace(s) it contains so the compiler can figure out what 
 assembly to use when you use a namespace.
 I might want to store a single namespace/package in multiple folders, 
 for example to separate the implementation into /win32 /linux etc...
 
 The downside to this is that it's a little more complicated.
 The tool chain should also provide a reverse lookup from a 
 symbol/namespace to any assemblies that contain it, probably a compiler 
 flag.


Well I was just growing fonder of the fact that there's a 1:1 
correspondence between file and module, and between package and 
directory. It's simple, easy to explain, and benefits of everything the 
OS offers in terms of management.

Also, to me it looks like files and directories are subject to similar 
scale issues as modules and packages.


Andrei
Oct 31 2009
parent reply yigal chripun <yigal100 gmail.com> writes:
Andrei Alexandrescu Wrote:


 Yigal Chripun wrote:

 On 31/10/2009 19:21, Andrei Alexandrescu wrote:

 Has anyone been irked by this? If you have a module called 5th-element.d
 there is no way to import that. I don't think it's a major issue, but
 I'm also seeing it as a limitation that should have a better explanation.

 One way to circumvent that may be

 import fifth = "5th-element.d";

 i.e., specify the file as a string and assign to it a regular D
 identifier. Probably similar things have been discussed in the past,
 what's the general impression?


 Andrei


 
 IMO physical storage should be orthogonal to logical structure of the 

 what namespace(s) it contains so the compiler can figure out what 
 assembly to use when you use a namespace.
 I might want to store a single namespace/package in multiple folders, 
 for example to separate the implementation into /win32 /linux etc...
 
 The downside to this is that it's a little more complicated.
 The tool chain should also provide a reverse lookup from a 
 symbol/namespace to any assemblies that contain it, probably a compiler 
 flag.


 
 Well I was just growing fonder of the fact that there's a 1:1 
 correspondence between file and module, and between package and 
 directory. It's simple, easy to explain, and benefits of everything the 
 OS offers in terms of management.
 
 Also, to me it looks like files and directories are subject to similar 
 scale issues as modules and packages.
 
 
 Andrei


Yes, it's a little simpler but also less flexible. This 1:1 mapping has all the
benefits and also all the drawbacks of the OS management. For instance, there
the issue of case sensitivity: D is case sensitive but the win FS isn't.

This tight mapping is also a problem when you want to rearange physical
structure without affecting the API -  e.g. a module had grown to be too big
and you want to split it into multiple files. std.algorithm is a prime example
of such way too big module. 

I agree that fully separating the two concepts is more complex but the current
system is just too strict to my liking. At least some compromise solution that
allows more flexibility is needed.
Nov 01 2009
parent Christopher Wright <dhasenan gmail.com> writes:
yigal chripun wrote:

 This tight mapping is also a problem when you want to rearange physical
structure without affecting the API -  e.g. a module had grown to be too big
and you want to split it into multiple files. std.algorithm is a prime example
of such way too big module. 


What about public imports? Tango does this. The old import will contain 
a pragma(msg) telling you what you should import instead, and maybe some 
aliases in case some functions or types changed names as well.
Nov 01 2009
prev sibling next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Andrei Alexandrescu, el 31 de octubre a las 12:21 me escribiste:

 Has anyone been irked by this? If you have a module called
 5th-element.d there is no way to import that. I don't think it's a
 major issue, but I'm also seeing it as a limitation that should have
 a better explanation.
 
 One way to circumvent that may be
 
 import fifth = "5th-element.d";
 
 i.e., specify the file as a string and assign to it a regular D
 identifier. Probably similar things have been discussed in the past,
 what's the general impression?


I see this as a non-problem. I usually like short module names, because is
something I have to write all the time since I usually use static or
aliased imports (to be able to keep track of the origin of each symbol).
I even think imports should be "static" by default, but that's another
topic. The thing is, the current scheme tends to make you think about
short and simple module names; and I like that.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
- Tata Dios lo creó a usté solamente pa despertar al pueblo y fecundar
  las gayinas.
- Otro constrasentido divino... Quieren que yo salga de joda con las
  hembras y después quieren que madrugue.
	-- Inodoro Pereyra y un gallo
Oct 31 2009
prev sibling parent Justin Johansson <no spam.com> writes:
Andrei Alexandrescu Wrote:


 Has anyone been irked by this? If you have a module called 5th-element.d 
 there is no way to import that. I don't think it's a major issue, but 
 I'm also seeing it as a limitation that should have a better explanation.
 
 One way to circumvent that may be
 
 import fifth = "5th-element.d";
 
 i.e., specify the file as a string and assign to it a regular D 
 identifier. Probably similar things have been discussed in the past, 
 what's the general impression?
 
 
 Andrei


I'm irked that it seems like you cannot use keywords as module names.

Say if one were writing a compiler for the next big language in D, then it
would be reasonable to expect that you could have a D source file called
scope.d, module.d etc.

Unfortunately as a consequence of this you cannot write (with DMD 1 compiler at
least)

import nextBigLanguage.scope;
import nextBigLanguage.module;

Maybe there is some work-around but, even if there is a work-around, for
something like this, it is not nice.

-- Justin Johansson
Nov 21 2009