Isaac Dupree <m...@isaac.cedarswampstudios.org> writes: My proposal:
>> A module may be defined in a file with a name corresponding to the >> module name, or any dot-separated prefix of it. I.e. the file >> Foo/Bar.hs will define module Foo.Bar and optionally Foo.Bar.Baz as >> well. > Note though, that local modules tempt us to a couple other things too, even > though they're not necessary to the proposal and would complicate it: > - access-controlled modules (e.g. if other code can't import Foo.Bar.Baz) This has been requested on and off, typically exposing internals for testing purposes. > - relative-path imports / module names (e.g. if in Foo/Bar.hs we make Baz and > try to import it some way with "import Baz") My choice would be to be cavalier about it, and sweep these under the orthogonality carpet :-) I'm not convinced they would complicate things - not a lot, at any rate. If possible the system should be designed so that sub-modules should behave just as if they were defined in files in the appropriate subdirectory. Is it possible? OTOH, a bonus would be that you might avoid the need to bootstrap recursive modules if you put them in the same file? > and as we already mentioned, it would likely involve some implicit importing > of the sub-module. I must have missed this, could you help me with a pointer? > I think my module-search mechanism makes a well-defined, deterministic way to > find the right module Yes. > Implicit importing: submodule syntax implies adding an "import > The.Module.Name" line at that point in the containing file. I'm not sure I agree with that, I don't see why we shouldn't treat these modules as ordinary modules. One of the motivations for doing this is to qualify record labels - not being able to specify "import .. qualified" or "as ..." seems like rather a loss. > This would suggest that submodules must be at the top, among the > imports, because all imports must syntactically be at the beginning > of the file -- and there's a reason for this. Which is? Do we avoid one pass, or what? > so an example could be > > module MyData > ( > module MyData.Sub, -- or equivalently, D(..) > transform > ) > where -- so I would require this as well, import MyData.Sub (transform, D(..)) > module MyData.Sub --or "module Sub" ?? that seems a bit too ad-hoc though > where > data D = E | F > > transform :: D -> D > transform F = E > transform E = F Another example: ------------------------------ module Foo where import qualified Foo.Bar as Bar import Foo.Zot f z = x z -- z = Zot.z, f :: Z -> Float g b = Bar.x b + Bar.y b ... module Foo.Bar where data B = B { x, y :: Int } ... module Foo.Zot where data Z = Z { x :: Float } ... ------------------------------ I'd make an exception for Main, which would count as no top-level module, and thus allow module Main where import ... import Sub ... module Sub where -- not Main.Sub, but possibly FileName.Sub? import ... ... -k -- If I haven't seen further, it is by standing in the footprints of giants _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe