PROPOSAL: Literate haskell and module file names
marlowsd at gmail.com
Wed Mar 26 08:29:10 UTC 2014
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
> On Sun, Mar 16, 2014 at 1:14 PM, Merijn Verstraaten
> <merijn at inconsistent.nl <mailto:merijn at 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.
> 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.
>> On Sun, Mar 16, 2014 at 8:56 AM, Merijn Verstraaten
>> <merijn at inconsistent.nl <mailto:merijn at inconsistent.nl>> wrote:
>> 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.
>> - 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
>> - Someone has to implement it
>> - ??
>> Discussion: 4 weeks
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> <mailto:Glasgow-haskell-users at haskell.org>
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
More information about the Glasgow-haskell-users