From merijn at inconsistent.nl Sun Mar 16 12:56:34 2014 From: merijn at inconsistent.nl (Merijn Verstraaten) Date: Sun, 16 Mar 2014 13:56:34 +0100 Subject: PROPOSAL: Literate haskell and module file names Message-ID: 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From ekmett at gmail.com Sun Mar 16 15:41:12 2014 From: ekmett at gmail.com (Edward Kmett) Date: Sun, 16 Mar 2014 11:41:12 -0400 Subject: PROPOSAL: Literate haskell and module file names In-Reply-To: References: Message-ID: 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 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: From merijn at inconsistent.nl Sun Mar 16 17:14:12 2014 From: merijn at inconsistent.nl (Merijn Verstraaten) Date: Sun, 16 Mar 2014 18:14:12 +0100 Subject: PROPOSAL: Literate haskell and module file names In-Reply-To: References: Message-ID: 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 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From ekmett at gmail.com Mon Mar 17 13:08:01 2014 From: ekmett at gmail.com (Edward Kmett) Date: Mon, 17 Mar 2014 09:08:01 -0400 Subject: PROPOSAL: Literate haskell and module file names In-Reply-To: References: Message-ID: 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 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: From allbery.b at gmail.com Mon Mar 17 13:22:10 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 17 Mar 2014 09:22:10 -0400 Subject: PROPOSAL: Literate haskell and module file names In-Reply-To: References: Message-ID: On Mon, Mar 17, 2014 at 9:08 AM, Edward Kmett wrote: > Foo+rst.lhs does nicely dodge the collision with jhc. > Is this legal on Windows? -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From svenpanne at gmail.com Mon Mar 17 13:35:32 2014 From: svenpanne at gmail.com (Sven Panne) Date: Mon, 17 Mar 2014 14:35:32 +0100 Subject: PROPOSAL: Literate haskell and module file names In-Reply-To: References: Message-ID: 2014-03-17 14:22 GMT+01:00 Brandon Allbery : > On Mon, Mar 17, 2014 at 9:08 AM, Edward Kmett wrote: >> >> Foo+rst.lhs does nicely dodge the collision with jhc. > > > Is this legal on Windows? According to http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx it is, although I can't test this at the moment. From marlowsd at gmail.com Wed Mar 26 08:29:10 2014 From: marlowsd at gmail.com (Simon Marlow) Date: Wed, 26 Mar 2014 08:29:10 +0000 Subject: PROPOSAL: Literate haskell and module file names In-Reply-To: References: Message-ID: <53328FD6.8050700@gmail.com> 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 > > 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 >> > 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 >> >> > > > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >