Re: importing modules with non-identifier names
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
Re: importing modules with non-identifier names
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 code. This is why I like the C# way of namespaces. Each assembly knows 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.
Re: importing modules with non-identifier names
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.
importing modules with non-identifier names
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
Re: importing modules with non-identifier names
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
Re: importing modules with non-identifier names
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
Re: importing modules with non-identifier names
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).
Re: importing modules with non-identifier names
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) { ... }
Re: importing modules with non-identifier names
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 code. This is why I like the C# way of namespaces. Each assembly knows 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.
Re: importing modules with non-identifier names
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 code. This is why I like the C# way of namespaces. Each assembly knows 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
Re: importing modules with non-identifier names
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
