June 2014 - Glasgow-haskell-users

PROPOSAL: Literate haskell and module file names
by Merijn Verstraaten 23 Aug '14

23 Aug '14

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

10 17

ghc -M
by Christian Maeder 09 Jul '14

09 Jul '14

Hi, using "ghc -M" with ghc-7.8.2 under linux. I got a message: You must specify at least one -dep-suffix (and a failure). http://www.haskell.org/ghc/docs/7.8.1/html/users_guide/separate-compilation… I've stopped using "ghc -M" now, but I think it should be documented better. Maybe dynamic linking complicated matters. Cheers Christian

1 1

RFC: Unicode primes and super/subscript characters in GHC
by Mikhail Vorozhtsov 27 Jun '14

27 Jun '14

Hello lists, As some of you may know, GHC's support for Unicode characters in lexemes is rather crude and hence prone to inconsistencies in their handling versus the ASCII counterparts. For example, APOSTROPHE is treated differently from PRIME: λ> data a +' b = Plus a b <interactive>:3:9: Unexpected type ‘b’ In the data declaration for ‘+’ A data declaration should have form data + a b c = ... λ> data a +′ b = Plus a b λ> let a' = 1 λ> let a′ = 1 <interactive>:10:8: parse error on input ‘=’ Also some rather bizarre looking things are accepted: λ> let ᵤxᵤy = 1 In the spirit of improving things little by little I would like to propose: 1. Handle single/double/triple/quadruple Unicode PRIMEs the same way as APOSTROPHE, meaning the following alterations to the lexer: primes -> U+2032 | U+2033 | U+2034 | U+2057 symbol -> ascSymbol | uniSymbol (EXCEPT special | _ | " | ' | primes) graphic -> small | large | symbol | digit | special | " | ' | primes varid -> (small { small | large | digit | ' | primes }) (EXCEPT reservedid) conid -> large { small | large | digit | ' | primes } 2. Introduce a new lexer nonterminal "subsup" that would include the Unicode sub/superscript[1] versions of numbers, "-", "+", "=", "(", ")", Latin and Greek letters. And allow these characters to be used in names and operators: symbol -> ascSymbol | uniSymbol (EXCEPT special | _ | " | ' | primes | subsup ) digit -> ascDigit | uniDigit (EXCEPT subsup) small -> ascSmall | uniSmall (EXCEPT subsup) | _ large -> ascLarge | uniLarge (EXCEPT subsup) graphic -> small | large | symbol | digit | special | " | ' | primes | subsup varid -> (small { small | large | digit | ' | primes | subsup }) (EXCEPT reservedid) conid -> large { small | large | digit | ' | primes | subsup } varsym -> (symbol (EXCEPT :) {symbol | subsup}) (EXCEPT reservedop | dashes) consym -> (: {symbol | subsup}) (EXCEPT reservedop) If this proposal is received favorably, I'll write a patch for GHC based on my previous stab at the problem[2]. P.S. I'm CC-ing Cafe for extra attention, but please keep the discussion to the GHC users list. [1] https://en.wikipedia.org/wiki/Unicode_subscripts_and_superscripts [2] https://ghc.haskell.org/trac/ghc/ticket/5108

5 9

RE: Associated type instances
by Simon Peyton Jones 24 Jun '14

24 Jun '14

I'm not sure when this "feature" was added, but I'm pretty sure that my original implementation of associated types was exactly what you describe in the solution. Or did I miss anything? I think you are right. I think I added the new stuff in a fit of enthusiasm one day, a fit that I am now regretting! But I'm just checking that no one has meanwhile become addicted to it. Simon From: Manuel Chakravarty [mailto:mchakravarty@me.com] Sent: 24 June 2014 08:54 To: Simon Peyton Jones Cc: GHC List; ghc-devs(a)haskell.org Subject: Re: Associated type instances Simon, I'm not sure when this "feature" was added, but I'm pretty sure that my original implementation of associated types was exactly what you describe in the solution. Or did I miss anything? Manuel Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>>: Friends I want to make withdraw (or, rather, simplify) a little-known feature in GHC, but before I do so I want to check that no one is going to have a heart attack. Relevant bits of the user manual: http://www.haskell.org/ghc/docs/latest/html/users_guide/type-families.html#… All of this arose when thinking about fixing Trac #9063. I believe that this change will affect essentially nobody, and I propose to implement forthwith in HEAD (and hence 7.10). Does anyone object? Thanks Simon The issue Consider this: class C a where type T a b :: * instance C [x] where type T [x] b = x -> b That is just what you'd expect. But currently this is allowed too: instance C [x] where type T [x] Int = x -> Int type T [x] Bool = Bool -> x That is, GHC 7.8 allows many associated type instances, provided they don't overlap. But, oddly you can't further instantiate the instance pattern. This would make just as much sense, but isn't allowed: instance C [x] where type T [Int] b = b -> Int type T [Bool] b = Bool -> b Moreover, as the user manual says, for an open kind like *, none of this really makes sense. It really only makes sense for a closed kind. Something like class D a where type S (b :: Bool) a :: * Now this would make some kind of sense: instance D [x] where type S True [x] = x -> x type S False [x] = x But for closed kinds, you really want a closed type family. So this would be better: instance D [x] where type S b [x] = SHelp x b type family SHelp x b where SHelp x True = x -> x SHelp x False = x So yes, you do have to declare a named helper type, but you get something much more perspicuous and explicit in exchange. All of this also applies to the default declaration(s) which you can supply for an associated type (see 7.7.3.2 in the link above), only it's a bit more complicated and indirect. My solution I propose to simplify substantially, as follows: * The "shared arguments" of an associated type are the argument positions that mention a type variable from the class header. So in class C above, the first argument position of T is "shared"; and in class D, the second argument position of S is shared. * A instance for an associated type (in a class instance declaration) cf 7.7.3.1 must have o type variables in the non-shared argument positions, and o an exact copy of the corresponding instance header type in the shared positions * For each associated type you can have o at most one default declaration in the class declaration o at most one type instance declaration in the class instance declaration _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> http://www.haskell.org/mailman/listinfo/ghc-devs

2 2

Associated type instances
by Simon Peyton Jones 24 Jun '14

24 Jun '14

Friends I want to make withdraw (or, rather, simplify) a little-known feature in GHC, but before I do so I want to check that no one is going to have a heart attack. Relevant bits of the user manual: http://www.haskell.org/ghc/docs/latest/html/users_guide/type-families.html#… All of this arose when thinking about fixing Trac #9063. I believe that this change will affect essentially nobody, and I propose to implement forthwith in HEAD (and hence 7.10). Does anyone object? Thanks Simon The issue Consider this: class C a where type T a b :: * instance C [x] where type T [x] b = x -> b That is just what you'd expect. But currently this is allowed too: instance C [x] where type T [x] Int = x -> Int type T [x] Bool = Bool -> x That is, GHC 7.8 allows many associated type instances, provided they don't overlap. But, oddly you can't further instantiate the instance pattern. This would make just as much sense, but isn't allowed: instance C [x] where type T [Int] b = b -> Int type T [Bool] b = Bool -> b Moreover, as the user manual says, for an open kind like *, none of this really makes sense. It really only makes sense for a closed kind. Something like class D a where type S (b :: Bool) a :: * Now this would make some kind of sense: instance D [x] where type S True [x] = x -> x type S False [x] = x But for closed kinds, you really want a closed type family. So this would be better: instance D [x] where type S b [x] = SHelp x b type family SHelp x b where SHelp x True = x -> x SHelp x False = x So yes, you do have to declare a named helper type, but you get something much more perspicuous and explicit in exchange. All of this also applies to the default declaration(s) which you can supply for an associated type (see 7.7.3.2 in the link above), only it's a bit more complicated and indirect. My solution I propose to simplify substantially, as follows: * The "shared arguments" of an associated type are the argument positions that mention a type variable from the class header. So in class C above, the first argument position of T is "shared"; and in class D, the second argument position of S is shared. * A instance for an associated type (in a class instance declaration) cf 7.7.3.1 must have o type variables in the non-shared argument positions, and o an exact copy of the corresponding instance header type in the shared positions * For each associated type you can have o at most one default declaration in the class declaration o at most one type instance declaration in the class instance declaration

2 1

Monomorphizing GHC Core?
by Conal Elliott 20 Jun '14

20 Jun '14

Has anyone worked on a monomorphizing transformation for GHC Core? I understand that polymorphic recursion presents a challenge, and I do indeed want to work with polymorphic recursion but only on types for which the recursion bottoms out statically (i.e., each recursive call is on a smaller type). I'm aiming at writing high-level polymorphic code and generating monomorphic code on unboxed values. This work is part of a project for compiling Haskell to hardware, described on my blog (http://conal.net) Thanks, - Conal

3 4

Re: Regression in the typechecker in GHC 7.8.2
by John Wiegley 16 Jun '14

16 Jun '14

>>>>> Simon Peyton Jones <simonpj(a)microsoft.com> writes: > Copying ghc-devs. Oleg says: > | Sorry for reporting a problem via e-mail. It seems track no > | longer accepts anonymous (guest) submissions. When I tried to register > | the account I was told that my submission is a spam. The tracker is > | really well protected. > Can anyone help him? I'll open a ticket. This has been discussed before BTW: http://comments.gmane.org/gmane.comp.lang.haskell.ghc.devel/4239 So it looks like Herbert is the one to contact. John

1 0

AlternateLayoutRule
by John Meacham 10 Jun '14

10 Jun '14

Hi, I noticed that ghc now supports an 'AlternateLayoutRule' but am having trouble finding information about it. Is it based on my proposal and sample implementation? http://www.mail-archive.com/haskell-prime@haskell.org/msg01938.html https://ghc.haskell.org/trac/haskell-prime/wiki/AlternativeLayoutRule implies it has been in use since 6.13. If that is the case, I assume it has been found stable? I ask because I was going to rewrite the jhc lexer and would like to use the new mechanism in a way that is compatible with ghc. If it is already using my code, so much the better. John -- John Meacham - http://notanumber.net/

3 8

Command line options for forcing 98 and 2010 mode
by John Meacham 03 Jun '14

03 Jun '14

Something that would be useful is command line options that will make ghc conform to the standards in one shot. I have various programs that conform to the standards and the onlyrce of incompatibility is the changing options needed to get ghc to compile them. This is analogous to how hugs has the -98 flag and the C standard specifies that 'c99' is an alias to your C compiler that enforces full ISO c99 compatibility. I was thinking providing ghc98 and ghc2010 command aliases, or making an option '--std=haskell98'. another option would be to have -XHaskell98 also modify the package imports in addition to language features, but this may be undesireable as then it would behave differently when specified in a LANGUAGE pragma. John -- John Meacham - http://notanumber.net/

1 0