Foo+rst.lhs does nicely dodge the collision with jhc. How does ghc do the search now? By trying each alternative in turn?
On Sun, Mar 16, 2014 at 1:14 PM, Merijn Verstraaten <mer...@inconsistent.nl>wrote: > 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 Foois > 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-users@haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> >> > >
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
