- Glasgow-haskell-users

Re: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation?
by Luite Stegeman 04 Jul '14

04 Jul '14

On Thu, Jul 3, 2014 at 6:18 PM, Simon Peyton Jones <simonpj(a)microsoft.com> wrote: > Luite > > > > I lack the bandwidth to respond at any technical depth, but I’d like to > make encouraging noises. If you can figure out a way to make GHC do these > things without making the compiler terribly complicated and making > maintaining it harder, then I’m open to your proposals. > > > I think most of the communication code could go into a separate executable that can be built by the user for the target-specific communication. The GHC API facing part of the implementation in GHCJS is under 300 lines and that includes some non-exported code duplicated from GHC, so I'm reasonably optimistic that it can be done without too much impact. Unfortunately I won't have much time in the near future, since a GHCJS release is well overdue (mostly because I keep adding features like this...) and I want to focus on that first, but getting it ready before 7.10 should be doable (especially if other people want to help!) luite

1 0

Closed type families, apartness, and occurs check
by Brandon Moore 02 Jul '14

02 Jul '14

>From the user manual, it sounds like a clause of a closed type family should be rejected once no subsitution of the type could make it unify with the clause. If so, it doesn't seem to do an occurs check: type family IsEq a b :: Bool where IsEq a a = True IsEq a b = False > :kind! forall a . IsEq a a forall a . IsEq a a :: Bool = forall (a :: k). 'True > :kind! forall a . IsEq a [a] forall a . IsEq a [a] :: Bool = forall a. IsEq a [a] I came across this while trying to using Generics to find the immediate children of a term - this sort of non-reduction happens while comparing a type like (Term var) with a constructor argument of type var. Brandon

2 3

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 21 Jun '14

21 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

Data.Type.Equality.== works better when used at kind * -> * -> Bool
by adam vogt 31 May '14

31 May '14

Hello List, Given the following definitions: > class HEq (x :: k) (y :: k) (b :: Bool) | x y -> b > instance ((Proxy x == Proxy y) ~ b) => HEq x y b -- (A) > instance ((x == y) ~ b) => HEq x y b -- (B) The instance (A) lets HList compile, which can be reproduced with: darcs get http://code.haskell.org/~aavogt/HList/ cd HList cabal install -fnew_type_eq When I select instance (B) instead by uncommenting the alternative instance in Data/HList/FakePrelude.hs, one of the more informative type errors suggests that the == type family is getting stuck: Data/HList/Variant.hs:202:29: Warning: Could not deduce (HasField' (l Data.Type.Equality.== l) l (Tagged l (Maybe e) : v) (Maybe e)) arising from a use of ‘mkVariant’ from the context (ConvHList p, SameLength' v v, HMapCxt HMaybeF p v, le ~ Tagged l (Maybe e)) Does this suggest that type (==) should work with all kinds, as it would with: > type a == b = Proxy a `EqStar` Proxy b https://github.com/ghc/packages-base/blob/master/Data/Type/Equality.hs mentions "A poly-kinded instance is /not/ provided, as a recursive definition for algebraic kinds is generally more useful.", but are there instances of (==) that behave differently from the poly-kinded version? Regards, Adam

2 1