I agree that this could collide, see my beginning remark that I believe that the report should provide a minimal specification how to map modules to filenames and vice versa.
Anyhoo, I'm not married to this specific suggestion. Carter suggested "Foo+rst.lhs" on IRC, other options would be "Foo.rst+lhs" or "Foo.lhs+rst", I don't particularly care what as long as we pick something. Patching tools to support whatever solution we pick should be trivial. Cheers, Merijn On Mar 16, 2014, at 16:41 , Edward Kmett wrote: > One problem with Foo.*.hs or even Foo.md.hs mapping to the module name Foo is > that as I recall JHC will look for Data.Vector in Data.Vector.hs as well as > Data/Vector.hs > > This means that on a case insensitive file system Foo.MD.hs matches both > conventions. > > Do I want to block an change to GHC because of an incompatible change in > another compiler? Not sure, but I at least want to raise the issue so it can > be discussed. > > Another small issue is that this means you need to actually scan the > directory rather than look for particular file names, but off my head really > I don't expect directories to be full enough for that to be a performance > problem. > > -Edward > > > > On Sun, Mar 16, 2014 at 8:56 AM, Merijn Verstraaten <mer...@inconsistent.nl> > wrote: > Ola! > > I didn't know what the most appropriate venue for this proposal was so I > crossposted to haskell-prime and glasgow-haskell-users, if this isn't the > right venue I welcome advice where to take this proposal. > > Currently the report does not specify the mapping between filenames and > module names (this is an issue in itself, it essentially makes writing > haskell code that's interoperable between compilers impossible, as you can't > know what directory layout each compiler expects). I believe that a minimal > specification *should* go into the report (hence, haskell-prime). However, > this is a separate issue from this proposal, so please start a new thread > rather than sidetracking this one :) > > The report only mentions that "by convention" .hs extensions imply normal > haskell and .lhs literate haskell (Section 10.4). In the absence of guidance > from the report GHC's convention of mapping module Foo.Bar.Baz to > Foo/Bar/Baz.hs or Foo/Bar/Baz.lhs seems the only sort of standard that > exists. In general this standard is nice enough, but the mapping of literate > haskell is a bit inconvenient, it leaves it completelyl ambiguous what the > non-haskell content of said file is, which is annoying for tool authors. > > Pandoc has adopted the policy of checking for further file extensions for > literate haskell source, e.g. Foo.rst.lhs and Foo.md.lhs. Here .rst.lhs gets > interpreted as being reStructured Text with literate haskell and .md.lhs is > Markdown with literate haskell. Unfortunately GHC currently maps filenames > like this to the module names Foo.rst and Foo.md, breaking anything that > wants to import the module Foo. > > I would like to propose allowing an optional extra extension in the pandoc > style for literate haskell files, mapping Foo.rst.lhs to module name Foo. > This is a backwards compatible change as there is no way for Foo.rst.lhs to > be a valid module in the current GHC convention. Foo.rst.lhs would map to > module name "Foo.rst" but module name "Foo.rst" maps to filename "Foo/rst.hs" > which is not a valid haskell module anyway as the rst is lowercase and module > names have to start with an uppercase letter. > > Pros: > - Tool authors can more easily determine non-haskell content of literate > haskell files > - Currently valid module names will not break > - Report doesn't specify behaviour, so GHC can do whatever it likes > > Cons: > - Someone has to implement it > - ?? > > Discussion: 4 weeks > > Cheers, > Merijn > > > _______________________________________________ > Glasgow-haskell-users mailing list > glasgow-haskell-us...@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > >
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
