On 17/03/2014 13:08, Edward Kmett wrote:
Foo+rst.lhs does nicely dodge the collision with jhc.
How does ghc do the search now? By trying each alternative in turn?
Yes - see compiler/main/Finder.hs
Cheers,
Simon
On Sun, Mar 16, 2014 at 1:14 PM, Merijn Verstraaten
<mer...@inconsistent.nl <mailto: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 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 <mailto: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
<mailto:glasgow-haskell-us...@haskell.org>
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
_______________________________________________
Glasgow-haskell-users mailing list
glasgow-haskell-us...@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
