digitalmars.D - module keyword with curly brackets
- tcak (18/18) Nov 01 2014 The "module" declaration, and the name and path of D files do not
- bearophile (5/6) Nov 01 2014 What advantages gives removing that "limitation"? Is the price in
- ketmar via Digitalmars-d (4/10) Nov 01 2014 nested modules, like in Modula. which were of almost no use and were
- Paulo Pinto (12/22) Nov 01 2014 A few languages have nested packages. Quite usefull for implementation
- ketmar via Digitalmars-d (8/34) Nov 01 2014 =20
- tcak (6/18) Nov 01 2014 Okay let's ignore nesting them, and let's just be able to defined
- ketmar via Digitalmars-d (4/7) Nov 01 2014 if they are so similar, put them in one module. if they aren't so
- Dicebot (4/8) Nov 01 2014 I am afraid you need to get used to it because it is fundamental
- Walter Bright (7/9) Nov 01 2014 Cramming lots of code into one source file made abundant sense on floppy...
- H. S. Teoh via Digitalmars-d (22/35) Nov 01 2014 I've tried on one or two occasions to split std.algorithm into more
- Joakim (11/16) Nov 01 2014 I've proposed an enhancement to dfix that should help with this:
- Jonathan M Davis via Digitalmars-d (5/8) Nov 02 2014 Breaking it up isn't all that hard, just somewhat time-consuming, and I
- Daniel Murphy (3/5) Nov 01 2014 I doubt it.
- Jonathan M Davis via Digitalmars-d (6/24) Nov 01 2014 In D, packages correspond to directories, and modules correspond to file...
- Nicolas Sicard (9/44) Nov 01 2014 What's the reason why the module keyword was introduced in the
- ketmar via Digitalmars-d (6/10) Nov 01 2014 no, it can't. assume i have a file "foo.d". in what package it should
- Dicebot (8/15) Nov 01 2014 You can omit module declarations and those will be deduced indeed.
- Nicolas Sicard (11/27) Nov 01 2014 Compiling is already dependent on the current directory. And
- Dicebot (7/26) Nov 01 2014 Ah yes, damnation, I keep forgetting about this one. In my
- Nicolas Sicard (10/37) Nov 01 2014 Actually, I don't think it's a bug. The current model is
- Walter Bright (3/5) Nov 01 2014 Sometimes it can be handy to have a module name different from a file na...
- Mike (11/29) Nov 01 2014 I find this, and the fact that packages and modules map directly
- Dicebot (5/8) Nov 01 2014 It is not necessary but it results in elegant mapping. I wish it
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
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
On Sat, 01 Nov 2014 09:24:46 +0000 bearophile via Digitalmars-d <digitalmars-d puremagic.com> wrote:tcak: =20nested modules, like in Modula. which were of almost no use and were removed in Oberon.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?
Nov 01 2014
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: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. -- Paulotcak:nested modules, like in Modula. which were of almost no use and were removed in Oberon.Is there any VERY SPECIAL reason behind that limitation?What advantages gives removing that "limitation"? Is the price in increased complexity worth paying?
Nov 01 2014
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:=20On Sat, 01 Nov 2014 09:24:46 +0000 bearophile via Digitalmars-d <digitalmars-d puremagic.com> wrote:=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,=tcak:nested modules, like in Modula. which were of almost no use and were removed in Oberon.Is there any VERY SPECIAL reason behind that limitation?What advantages gives removing that "limitation"? Is the price in increased complexity worth paying?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
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. -- PauloOkay 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
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
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
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
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'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 SmoorenburgI 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
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
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
"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
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
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: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? -- NicolasThe "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
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
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
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: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.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.Yes, I don't put them!
Nov 01 2014
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: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.On Saturday, 1 November 2014 at 14:03:51 UTC, Nicolas Sicard wrote: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?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.
Nov 01 2014
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: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 :)On Saturday, 1 November 2014 at 14:40:16 UTC, Dicebot wrote: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.On Saturday, 1 November 2014 at 14:03:51 UTC, Nicolas Sicard wrote: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?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.
Nov 01 2014
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
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 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
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