www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - module keyword with curly brackets

reply "tcak" <tcak gmail.com> writes:
The "module" declaration, and the name and path of D files do not 
need to match each other. You include a D file while compiling 
the project, and module declarations are cared only.

Based on above behaviour of design, allowing only one "module" 
keyword, and that is on top of D code file seems like a 
limitation to me (a little like just trying to copy Java, but 
leaving the work in the middle).

Is there any VERY SPECIAL reason behind that limitation? How hard 
would it be to add a syntax as below? What problems could it 
create?

test.d
----
module a{
}

module b{
    module c{
    }
}
Nov 01 2014
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
tcak:

 Is there any VERY SPECIAL reason behind that limitation?
What advantages gives removing that "limitation"? Is the price in increased complexity worth paying? Bye, bearophile
Nov 01 2014
next sibling parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sat, 01 Nov 2014 09:24:46 +0000
bearophile via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 tcak:
=20
 Is there any VERY SPECIAL reason behind that limitation?
=20 What advantages gives removing that "limitation"? Is the price in=20 increased complexity worth paying?
nested modules, like in Modula. which were of almost no use and were removed in Oberon.
Nov 01 2014
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 01.11.2014 um 10:29 schrieb ketmar via Digitalmars-d:
 On Sat, 01 Nov 2014 09:24:46 +0000
 bearophile via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 tcak:

 Is there any VERY SPECIAL reason behind that limitation?
What advantages gives removing that "limitation"? Is the price in increased complexity worth paying?
nested modules, like in Modula. which were of almost no use and were removed in Oberon.
A few languages have nested packages. Quite usefull for implementation packages. Beware of Wirth's quest for simplicity, even Go is a quite powerful in regards to Oberon-07. From my experience in the Oberon world, I got the feeling Wirth isn't that happy with Active Oberon and Zonnon in terms of language evolution, where he barely colaborated. Hence why he eventually came up with Oberon-07, which is even more minimalist than Oberon. -- Paulo
Nov 01 2014
next sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sat, 01 Nov 2014 11:04:32 +0100
Paulo Pinto via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 Am 01.11.2014 um 10:29 schrieb ketmar via Digitalmars-d:
 On Sat, 01 Nov 2014 09:24:46 +0000
 bearophile via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 tcak:

 Is there any VERY SPECIAL reason behind that limitation?
What advantages gives removing that "limitation"? Is the price in increased complexity worth paying?
nested modules, like in Modula. which were of almost no use and were removed in Oberon.
=20 A few languages have nested packages. Quite usefull for implementation=20 packages. =20 Beware of Wirth's quest for simplicity, even Go is a quite powerful in=20 regards to Oberon-07. =20 From my experience in the Oberon world, I got the feeling Wirth isn't=20 that happy with Active Oberon and Zonnon in terms of language evolution,=
=20
 where he barely colaborated.
=20
 Hence why he eventually came up with Oberon-07, which is even more=20
 minimalist than Oberon.
Modula-3 removed that feature too, AFAIR. that was considered needless complication that serves no practical purposes. as for Wirth's minimalism... i know, Oberon-1 doesn't even include FOR. ;-) i bet Wirth doesn't like vi for being too complicated and too far from text. ;-)
Nov 01 2014
prev sibling parent reply "tcak" <tcak gmail.com> writes:
On Saturday, 1 November 2014 at 10:04:23 UTC, Paulo Pinto wrote:
 Am 01.11.2014 um 10:29 schrieb ketmar via Digitalmars-d:

 A few languages have nested packages. Quite usefull for 
 implementation packages.

 Beware of Wirth's quest for simplicity, even Go is a quite 
 powerful in regards to Oberon-07.

 From my experience in the Oberon world, I got the feeling Wirth 
 isn't that happy with Active Oberon and Zonnon in terms of 
 language evolution, where he barely colaborated.

 Hence why he eventually came up with Oberon-07, which is even 
 more minimalist than Oberon.

 --
 Paulo
Okay let's ignore nesting them, and let's just be able to defined multiple modules without nesting them. My biggest concern is that just to collect similar things together (mostly small things), I have to create another new file which makes me feel "grrrrrrr".
Nov 01 2014
next sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sat, 01 Nov 2014 13:04:57 +0000
tcak via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 My biggest concern is that just to collect similar things
 together (mostly small things), I have to create another new file
 which makes me feel "grrrrrrr".
if they are so similar, put them in one module. if they aren't so similar, putting them in one source file will create smelling code.
Nov 01 2014
prev sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Saturday, 1 November 2014 at 13:04:58 UTC, tcak wrote:
 My biggest concern is that just to collect similar things
 together (mostly small things), I have to create another new 
 file
 which makes me feel "grrrrrrr".
I am afraid you need to get used to it because it is fundamental design decision of D module system and quite a feature on its own. Lot of files == awesome.
Nov 01 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/1/2014 6:31 AM, Dicebot wrote:
 I am afraid you need to get used to it because it is fundamental design
decision
 of D module system and quite a feature on its own. Lot of files == awesome.
Cramming lots of code into one source file made abundant sense on floppy disk systems, because switching files was so painfully slow. Of course, that problem disappeared 30 years ago. Nevertheless, Phobos has an obese kitchen-sink module problem anyway, so it's clear that those who want to cram it all into one file have any difficulties doing it :-)
Nov 01 2014
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Sat, Nov 01, 2014 at 03:23:17PM -0700, Walter Bright via Digitalmars-d wrote:
 On 11/1/2014 6:31 AM, Dicebot wrote:
I am afraid you need to get used to it because it is fundamental
design decision of D module system and quite a feature on its own.
Lot of files == awesome.
Cramming lots of code into one source file made abundant sense on floppy disk systems, because switching files was so painfully slow. Of course, that problem disappeared 30 years ago. Nevertheless, Phobos has an obese kitchen-sink module problem anyway, so it's clear that those who want to cram it all into one file have any difficulties doing it :-)
I've tried on one or two occasions to split std.algorithm into more manageable submodules. Unfortunately, it's not a trivial task due to over-reliance on module-global imports. Currently, it's so bad that I can't even run its unittests on my 1GB RAM 6-core CPU system anymore; I have to comment out two particularly memory-hogging unittests in order to not have the test abort prematurely with OOM. (Truth be told, though, it's partly my own fault -- the offending unittests are problematic because they trigger an exponential number of template instantiations in the 3rd overload of cartesianProduct, authored by yours truly. :-P I'm still trying to work out a way of preventing exponential template instantiations in that particular overload, which is non-trivial because it deals with infinite ranges.) We need a team of volunteers to tackle the behemoth that std.algorithm has become, and cut it back down to manageably-sized chunks. Jonathan was also reportedly working on breaking up std.datetime into manageable pieces, but it's been a long time and so far it seems to have been far easier said than done. So yeah, I'd say we have an obesity problem on our hands. :-P T -- Indifference will certainly be the downfall of mankind, but who cares? -- Miquel van Smoorenburg
Nov 01 2014
parent "Joakim" <dlang joakim.fea.st> writes:
On Sunday, 2 November 2014 at 01:59:10 UTC, H. S. Teoh via 
Digitalmars-d wrote:
 I've tried on one or two occasions to split std.algorithm into 
 more
 manageable submodules. Unfortunately, it's not a trivial task 
 due to
 over-reliance on module-global imports.
I've proposed an enhancement to dfix that should help with this: https://github.com/Hackerpilot/dfix/issues/10 It would be nice if we could automate such untangling of imports. I'm not sure how much work it would be to build it on top of the existing symbol finder in Dscanner (https://github.com/Hackerpilot/Dscanner/blob/master/src/symbol_finder.d), though one issue is that I'm not sure how to account for conditional compilation with libdparse yet. I'm going to try playing with that today.
Nov 01 2014
prev sibling parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Saturday, November 01, 2014 18:57:09 H. S. Teoh via Digitalmars-d wrote:
 Jonathan was also reportedly working on breaking up std.datetime into
 manageable pieces, but it's been a long time and so far it seems to have
 been far easier said than done.
Breaking it up isn't all that hard, just somewhat time-consuming, and I haven't been able to find the time to finish it yet, though I certainly hope to sometime soon. - Jonathan M Davis
Nov 02 2014
prev sibling parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"bearophile"  wrote in message news:aghnzoieibfgivzxapcc forum.dlang.org... 

 What advantages gives removing that "limitation"?
Multi-module single-file test cases!
 Is the price in increased complexity worth paying?
I doubt it.
Nov 01 2014
prev sibling next sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Saturday, November 01, 2014 07:52:38 tcak via Digitalmars-d wrote:
 The "module" declaration, and the name and path of D files do not
 need to match each other. You include a D file while compiling
 the project, and module declarations are cared only.

 Based on above behaviour of design, allowing only one "module"
 keyword, and that is on top of D code file seems like a
 limitation to me (a little like just trying to copy Java, but
 leaving the work in the middle).

 Is there any VERY SPECIAL reason behind that limitation? How hard
 would it be to add a syntax as below? What problems could it
 create?

 test.d
 ----
 module a{
 }

 module b{
     module c{
     }
 }
In D, packages correspond to directories, and modules correspond to files. Yes, the module and package names can vary slightly from the file name, but that doesn't change the fact that they still correspond to specific files, and most folks don't give the modules names that don't match their file names. - Jonathan M Davis
Nov 01 2014
parent reply "Nicolas Sicard" <dransic gmail.com> writes:
On Saturday, 1 November 2014 at 10:32:48 UTC, Jonathan M Davis 
via Digitalmars-d wrote:
 On Saturday, November 01, 2014 07:52:38 tcak via Digitalmars-d 
 wrote:
 The "module" declaration, and the name and path of D files do 
 not
 need to match each other. You include a D file while compiling
 the project, and module declarations are cared only.

 Based on above behaviour of design, allowing only one "module"
 keyword, and that is on top of D code file seems like a
 limitation to me (a little like just trying to copy Java, but
 leaving the work in the middle).

 Is there any VERY SPECIAL reason behind that limitation? How 
 hard
 would it be to add a syntax as below? What problems could it
 create?

 test.d
 ----
 module a{
 }

 module b{
     module c{
     }
 }
In D, packages correspond to directories, and modules correspond to files. Yes, the module and package names can vary slightly from the file name, but that doesn't change the fact that they still correspond to specific files, and most folks don't give the modules names that don't match their file names. - Jonathan M Davis
What's the reason why the module keyword was introduced in the first place? The package and module hierarchy could have been deduced from the directory and file hierarchy, as it is the case in Python, IIRC. The search rules just have to be clear. I know this has the side effect that module names can't be keywords or non-identifiers, but who would use such module names? -- Nicolas
Nov 01 2014
next sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sat, 01 Nov 2014 14:03:50 +0000
Nicolas Sicard via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 What's the reason why the module keyword was introduced in the=20
 first place? The package and module hierarchy could have been=20
 deduced from the directory and file hierarchy, as it is the case=20
 in Python, IIRC.
no, it can't. assume i have a file "foo.d". in what package it should be? ah, yes, i compiling that with 'dmd -c foo.d'. and... this is actually module with name 'mylib.internal.foo'. how to deduce that? traverse up by directory tree? and where dmd should stop then?
Nov 01 2014
prev sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Saturday, 1 November 2014 at 14:03:51 UTC, Nicolas Sicard 
wrote:
 What's the reason why the module keyword was introduced in the 
 first place? The package and module hierarchy could have been 
 deduced from the directory and file hierarchy, as it is the 
 case in Python, IIRC. The search rules just have to be clear. I 
 know this has the side effect that module names can't be 
 keywords or non-identifiers, but who would use such module 
 names?
You can omit module declarations and those will be deduced indeed. However that will make package path dependent on compiler currend directory and this is why specifying qualified path explicitly is helpful. I see no reason to put module declarations in single level projects with no packages.
Nov 01 2014
next sibling parent reply "Nicolas Sicard" <dransic gmail.com> writes:
On Saturday, 1 November 2014 at 14:40:16 UTC, Dicebot wrote:
 On Saturday, 1 November 2014 at 14:03:51 UTC, Nicolas Sicard 
 wrote:
 What's the reason why the module keyword was introduced in the 
 first place? The package and module hierarchy could have been 
 deduced from the directory and file hierarchy, as it is the 
 case in Python, IIRC. The search rules just have to be clear. 
 I know this has the side effect that module names can't be 
 keywords or non-identifiers, but who would use such module 
 names?
You can omit module declarations and those will be deduced indeed. However that will make package path dependent on compiler currend directory and this is why specifying qualified path explicitly is helpful.
Compiling is already dependent on the current directory. And qualified path are not just helpful, they're required for packages, or did I miss something? I was thinking about the way Python does it: - 'dmd foo.d' => 'import foo;' (if foo.d is in cwd) - 'dmd mylib/internal/foo.d' => 'import mylib.internal.foo;' (if the path exists in the cwd) - 'dmd foo.d' and there is no foo.d in the cwd: use the search path from the config, or fail.
 I see no reason to put module declarations in single level 
 projects with no packages.
Yes, I don't put them!
Nov 01 2014
parent reply "Dicebot" <public dicebot.lv> writes:
On Saturday, 1 November 2014 at 14:48:33 UTC, Nicolas Sicard 
wrote:
 On Saturday, 1 November 2014 at 14:40:16 UTC, Dicebot wrote:
 On Saturday, 1 November 2014 at 14:03:51 UTC, Nicolas Sicard 
 wrote:
 What's the reason why the module keyword was introduced in 
 the first place? The package and module hierarchy could have 
 been deduced from the directory and file hierarchy, as it is 
 the case in Python, IIRC. The search rules just have to be 
 clear. I know this has the side effect that module names 
 can't be keywords or non-identifiers, but who would use such 
 module names?
You can omit module declarations and those will be deduced indeed. However that will make package path dependent on compiler currend directory and this is why specifying qualified path explicitly is helpful.
Compiling is already dependent on the current directory. And qualified path are not just helpful, they're required for packages, or did I miss something?
Ah yes, damnation, I keep forgetting about this one. In my opinion it is a bug and it should indeed use reative folder path as package name. However fixing it can be hard because of possible build system breakage and stuff. Would be interesting to check that with dub & Co.
Nov 01 2014
parent "Nicolas Sicard" <dransic gmail.com> writes:
On Saturday, 1 November 2014 at 15:32:22 UTC, Dicebot wrote:
 On Saturday, 1 November 2014 at 14:48:33 UTC, Nicolas Sicard 
 wrote:
 On Saturday, 1 November 2014 at 14:40:16 UTC, Dicebot wrote:
 On Saturday, 1 November 2014 at 14:03:51 UTC, Nicolas Sicard 
 wrote:
 What's the reason why the module keyword was introduced in 
 the first place? The package and module hierarchy could have 
 been deduced from the directory and file hierarchy, as it is 
 the case in Python, IIRC. The search rules just have to be 
 clear. I know this has the side effect that module names 
 can't be keywords or non-identifiers, but who would use such 
 module names?
You can omit module declarations and those will be deduced indeed. However that will make package path dependent on compiler currend directory and this is why specifying qualified path explicitly is helpful.
Compiling is already dependent on the current directory. And qualified path are not just helpful, they're required for packages, or did I miss something?
Ah yes, damnation, I keep forgetting about this one. In my opinion it is a bug and it should indeed use reative folder path as package name. However fixing it can be hard because of possible build system breakage and stuff. Would be interesting to check that with dub & Co.
Actually, I don't think it's a bug. The current model is coherent: a package must be bound to a top-level directory. So the modules in the package must specify what this top-level directory is. What I meant is that I don't know what would be wrong in being able to do "dmd -I/path/to/phobos/std" and "import stdio;", that is if relative folder paths were used. The module statement wouldn't be necessary (apart for files like foo-bar.d). I should've asked in d.learn :)
Nov 01 2014
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/1/2014 7:40 AM, Dicebot wrote:
 I see no reason to put module declarations in single level projects with no
 packages.
Sometimes it can be handy to have a module name different from a file name, especially when trying to track down a bug, but this is rare.
Nov 01 2014
prev sibling parent reply "Mike" <none none.com> writes:
On Saturday, 1 November 2014 at 07:52:39 UTC, tcak wrote:
 The "module" declaration, and the name and path of D files do 
 not need to match each other. You include a D file while 
 compiling the project, and module declarations are cared only.

 Based on above behaviour of design, allowing only one "module" 
 keyword, and that is on top of D code file seems like a 
 limitation to me (a little like just trying to copy Java, but 
 leaving the work in the middle).

 Is there any VERY SPECIAL reason behind that limitation? How 
 hard would it be to add a syntax as below? What problems could 
 it create?

 test.d
 ----
 module a{
 }

 module b{
    module c{
    }
 }
I find this, and the fact that packages and modules map directly to directories and files, to be an arbitrary limitation as well. It was discussed briefly in Adam Wilson's talk at DConf 2013 "From C# to D" (http://www.youtube.com/watch?v=6_xdfSVRrKo). I also don't see any reason for there to be both packages and modules. But after about a year observing the culture of this community, I don't believe any of this will ever change unless the language is forked, in which case it will really no longer be D. Mike
Nov 01 2014
parent "Dicebot" <public dicebot.lv> writes:
On Saturday, 1 November 2014 at 14:18:53 UTC, Mike wrote:
 I find this, and the fact that packages and modules map 
 directly to directories and files, to be an arbitrary 
 limitation as well.
It is not necessary but it results in elegant mapping. I wish it pushed harder for module == namespace concept though. Also I'd prefer to use "package aaa.bbb;" notation and prohibit "module aaa.bbb.modname;" notation but that is purist dreaming :)
Nov 01 2014