From bjp at informatik.uni-kiel.de Thu Aug 7 13:16:00 2014 From: bjp at informatik.uni-kiel.de (=?UTF-8?B?QmrDtnJuIFBlZW3DtmxsZXI=?=) Date: Thu, 07 Aug 2014 15:16:00 +0200 Subject: Infix declaration: digit or integer? Message-ID: <53E37C10.8090908@informatik.uni-kiel.de> Hello Haskell-Prime, I just discovered that the Haskell 2010 report allows the precedence of infix declarations to be an integer instead of just a digit. Therefore, also the following declarations are allowed: -- compiles infix 0x7 <$> infix 0o7 <$> -- does not compile because of precedence out of range infix 0xa <$> infix 0oa <$> infix 123 <$> Interestingly, the in section 4.4.2 (Fixity Declarations) the report says: > The *integer* in a fixity declaration must be in the range 0 to 9. as well as > If the *digit* is omitted, level 9 is assumed. This is of course no problem, I'm just curious if there is some motivation for integer I'm not aware of. Kind Regards, Bj?rn From ekmett at gmail.com Tue Aug 12 17:20:22 2014 From: ekmett at gmail.com (Edward Kmett) Date: Tue, 12 Aug 2014 13:20:22 -0400 Subject: Proposal: Treat OtherLetter as lower case in the grammar Message-ID: Back in 2008 or so, GHC changed the behavior of unicode characters in the parser that parse as OtherLetter to make them parse as lower case so that languages like Japanese that lack case could be used in identifier names: https://ghc.haskell.org/trac/ghc/ticket/1103 In a recent thread on reddit Lennart Augustsson pointed out that this change was never backported to Haskell'. http://www.reddit.com/r/haskell/comments/2dce3d/%E0%B2%A0_%E0%B2%A0_string_a/cjo68ij Would it make sense to adopt this change in the language standard? Marlow when he made the change to GHC noted he was considering bringing it up to Haskell' but here we are 6 years later. -Edward Kmett -------------- next part -------------- An HTML attachment was scrubbed... URL: From a at lelf.me Thu Aug 14 15:53:39 2014 From: a at lelf.me (Antonio Nikishaev) Date: Thu, 14 Aug 2014 19:53:39 +0400 Subject: Proposal: Treat OtherLetter as lower case in the grammar References: Message-ID: I'd like to fix more of our unicode mess while we're at it. For example Mn (non-spacing combining marks) should allowed in varid_{cont}, so it won't be like this: h> let ?=() in ? () h> let x?=() in x? :6:6: lexical error at character '\769' (that?s because x? is denormalized and is actually 2 code points). [:Mc:] probably too. Also we can include include unicode ? ? ? ? primes (there's already a proposal for this IIRC). We have some prior work to look at, ? that is at least the java language specification and UAX #31. One problem is that doing it perfectly will require normalization (but there's always the java way ? to just ignore it). (I'm willing to formulate everything if there's some agreement to fix this.) Edward Kmett writes: > Back in 2008 or so, GHC changed the behavior of unicode characters in > the parser that parse as OtherLetter to make them parse as lower case > so that languages like Japanese that lack case could be used in > identifier names: > > https://ghc.haskell.org/trac/ghc/ticket/1103 > > In a recent thread on reddit Lennart Augustsson pointed out that this > change > was never backported to Haskell'. > > http://www.reddit.com/r/haskell/comments/2dce3d/%E0%B2%A0_%E0%B2%A0_string_ > a/cjo68ij > > Would it make sense to adopt this change in the language standard? > > Marlow when he made the change to GHC noted he was considering > bringing it up to Haskell' but here we are 6 years later. From merijn at inconsistent.nl Fri Aug 15 22:40:34 2014 From: merijn at inconsistent.nl (Merijn Verstraaten) Date: Fri, 15 Aug 2014 15:40:34 -0700 Subject: Revival: PROPOSAL: Literate haskell and module file names In-Reply-To: References: Message-ID: Ola! I raised this proposal earlier this year and got to busy to follow up, this week I was suddenly reminded and decided to reraise this. To summarise the discussion up until this point: There was no real opposition to the general idea, the only real objection to the original proposal was that ?Foo.lhs.md? and ?Foo.md.lhs? would collide with the naming scheme used by JHC on case insensitive filesystems. Alternative proposal raised during the discussion: "Foo+md.lhs", "Foo.lhs+md? and ?Foo.md+lhs?. According to MS documentation and testing the + should not be an issue on windows, the + doesn?t collide with any other haskell compiler (at least, not any I?m aware off) and since the report doesn?t specify any module name resolution mechanism, it does not conflict with the report either. My personal preferences goes to either ?.lhs+md? or ?.md+lhs?, since GHC currently tries every alternative in turn, I propose to just extend this list to look for any file whose extension is ?.lhs+*? or ?.*+lhs?. Are there any objections to this? If not, I?m just going to produce a patch + ticket as there were no real objections to the proposal last time. Cheers, Merijn On 16 Mar 2014, at 05:56 , 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 > -------------- 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 merijn at inconsistent.nl Sat Aug 16 21:05:55 2014 From: merijn at inconsistent.nl (Merijn Verstraaten) Date: Sat, 16 Aug 2014 14:05:55 -0700 Subject: Revival: PROPOSAL: Literate haskell and module file names In-Reply-To: <37030b7f674d4804b551a9c57753d586@EXMBX31.ad.utwente.nl> References: , <37030b7f674d4804b551a9c57753d586@EXMBX31.ad.utwente.nl> Message-ID: <7DB6F353-D3E5-4A44-9B73-2EAA2BEE9A89@inconsistent.nl> Hey Philip, This proposal is not because *GHC* needs to know anything about markdown/rST, in fact, GHC is already perfectly happy to take a literate haskell files that?s written in markdown, since it just strips the non-haskell bits and only compiles the haskell code. The problem is OTHER tools. For example, I have literate haskell files for my blog posts, how does my blog software know whether my lhs file is markdown, rST, TeX, or what not? I can just name my files using anyway I want (like ?Foo.md.lhs?) to have these tools detect the format, but then GHC will no longer compile my files. This is the problem I?m trying to solve with this proposal, once we settle on some extension format like this, it?s trivial to patch (for example) pandoc to use this to detect which contents are in the file. Cheers, Merijn On 16 Aug 2014, at 06:51 , p.k.f.holzenspies at utwente.nl wrote: > Dear Merijn, > > Do you even need a separate extension or filename convention for this? Can't you just call it lhs and expand the definition thereof to include markdown? (I suggested something similar before, but objections were raised that having too good and too broad an unlitter might lead to the bit-rot of the flag to employ external unlitters. I didn't quite understand that objection, but didn't pursue it) > > Regards, > Philip > > > ________________________________________ > Van: Glasgow-haskell-users namens Merijn Verstraaten > Verzonden: zaterdag 16 augustus 2014 00:40 > Aan: haskell-prime at haskell.org; glasgow-haskell-users at haskell.org > Onderwerp: Revival: PROPOSAL: Literate haskell and module file names > > Ola! > > I raised this proposal earlier this year and got to busy to follow up, this week I was suddenly reminded and decided to reraise this. To summarise the discussion up until this point: > > There was no real opposition to the general idea, the only real objection to the original proposal was that ?Foo.lhs.md? and ?Foo.md.lhs? would collide with the naming scheme used by JHC on case insensitive filesystems. Alternative proposal raised during the discussion: "Foo+md.lhs", "Foo.lhs+md? and ?Foo.md+lhs?. > > According to MS documentation and testing the + should not be an issue on windows, the + doesn?t collide with any other haskell compiler (at least, not any I?m aware off) and since the report doesn?t specify any module name resolution mechanism, it does not conflict with the report either. > > My personal preferences goes to either ?.lhs+md? or ?.md+lhs?, since GHC currently tries every alternative in turn, I propose to just extend this list to look for any file whose extension is ?.lhs+*? or ?.*+lhs?. > > Are there any objections to this? If not, I?m just going to produce a patch + ticket as there were no real objections to the proposal last time. > > Cheers, > Merijn > > On 16 Mar 2014, at 05:56 , 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 >> -------------- 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 merijn at inconsistent.nl Sat Aug 23 07:06:01 2014 From: merijn at inconsistent.nl (Merijn Verstraaten) Date: Sat, 23 Aug 2014 00:06:01 -0700 Subject: Revival: PROPOSAL: Literate haskell and module file names In-Reply-To: References:

<37030b7f674d4804b551a9c57753d586@EXMBX31.ad.utwente.nl> <7DB6F353-D3E5-4A44-9B73-2EAA2BEE9A89@inconsistent.nl> Message-ID: Right, given the lack of disagreement and past support for this I will implement whichever variant is simplest to implement/strikes my fancy and put a patch up on Trac. Cheers, Merijn On 16 Aug 2014, at 14:23 , Carter Schonwald wrote: > i personally think the .format+lhs pattern/convention is a good one, and prevents any misinterpretations that current plague literate tools + willl be treated as an unknown format rather than eagerly as .format or .lhs > > > On Sat, Aug 16, 2014 at 5:05 PM, Merijn Verstraaten wrote: > Hey Philip, > > This proposal is not because *GHC* needs to know anything about markdown/rST, in fact, GHC is already perfectly happy to take a literate haskell files that?s written in markdown, since it just strips the non-haskell bits and only compiles the haskell code. > > The problem is OTHER tools. For example, I have literate haskell files for my blog posts, how does my blog software know whether my lhs file is markdown, rST, TeX, or what not? I can just name my files using anyway I want (like ?Foo.md.lhs?) to have these tools detect the format, but then GHC will no longer compile my files. > > This is the problem I?m trying to solve with this proposal, once we settle on some extension format like this, it?s trivial to patch (for example) pandoc to use this to detect which contents are in the file. > > Cheers, > Merijn > > > On 16 Aug 2014, at 06:51 , p.k.f.holzenspies at utwente.nl wrote: > > Dear Merijn, > > > > Do you even need a separate extension or filename convention for this? Can't you just call it lhs and expand the definition thereof to include markdown? (I suggested something similar before, but objections were raised that having too good and too broad an unlitter might lead to the bit-rot of the flag to employ external unlitters. I didn't quite understand that objection, but didn't pursue it) > > > > Regards, > > Philip > > > > > > ________________________________________ > > Van: Glasgow-haskell-users namens Merijn Verstraaten > > Verzonden: zaterdag 16 augustus 2014 00:40 > > Aan: haskell-prime at haskell.org; glasgow-haskell-users at haskell.org > > Onderwerp: Revival: PROPOSAL: Literate haskell and module file names > > > > Ola! > > > > I raised this proposal earlier this year and got to busy to follow up, this week I was suddenly reminded and decided to reraise this. To summarise the discussion up until this point: > > > > There was no real opposition to the general idea, the only real objection to the original proposal was that ?Foo.lhs.md? and ?Foo.md.lhs? would collide with the naming scheme used by JHC on case insensitive filesystems. Alternative proposal raised during the discussion: "Foo+md.lhs", "Foo.lhs+md? and ?Foo.md+lhs?. > > > > According to MS documentation and testing the + should not be an issue on windows, the + doesn?t collide with any other haskell compiler (at least, not any I?m aware off) and since the report doesn?t specify any module name resolution mechanism, it does not conflict with the report either. > > > > My personal preferences goes to either ?.lhs+md? or ?.md+lhs?, since GHC currently tries every alternative in turn, I propose to just extend this list to look for any file whose extension is ?.lhs+*? or ?.*+lhs?. > > > > Are there any objections to this? If not, I?m just going to produce a patch + ticket as there were no real objections to the proposal last time. > > > > Cheers, > > Merijn > > > > On 16 Mar 2014, at 05:56 , 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 -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: