PROPOSAL: Literate haskell and module file names

[Edward Kmett]

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
<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.
>
> 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 <
> merijn at 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 at haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-prime/attachments/20140317/56c17ef7/attachment.html>