- Glasgow-haskell-users

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

ARM64 Task Force
by Luke Iannini 08 Jul '14

08 Jul '14

Howdy all, Would anyone like to team up on getting ARM64 support into GHC? Cheers Luke

1 0

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

06 Jul '14

hi all, I've added some code [1] [2] to GHCJS to make it run Template Haskell code on node.js, rather than using the GHC linker. GHCJS has supported TH for a long time now, but so far always relied on native (host) code for it. This is the main reason that GHCJS always builds native and JavaScript code for everything (another is that Cabal Setup.hs scripts need to be compiled to some host-runnable form, but that can also be JavaScript if you have node.js) Now besides the compiler having to do twice the work, this has some other disadvantages: - Our JavaScript code has the same dependencies (packages) as native code, which means packages like unix or Win32 show up somewhere, depending on the host environment. This also limits our options in choosing JS-specific packages. - The Template Haskell code runs on the host environment, which might be slightly different from the target, for example in integer size or operating system specific constants. Moreover, building native code made the GHCJS installation procedure more tricky, making end users think about libgmp or libiconv locations, since it basically required the same preparation as building GHC from source. This change will make installing much easier and more reliable (we still have to update the build scripts). How it works is pretty simple: - When any code needs to be run on the target (hscCompileCoreExpr, through the Hooks API new in GHC 7.8), GHCJS starts a node.js process with the thrunner.js [3] script, - GHCJS sends its RTS and the Template Haskell server code [1] to node.js, the script starts a Haskell thread running the server, - for every splice, GHCJS compiles it to JavaScript and links it using its incremental linking functionality. The code for the splice, including dependencies that have not yet been sent to the runner (for earlier splices), is then sent in a RunTH [4] message, - the runner loads and runs the code in the Q monad, can send queries to GHCJS for reification, - the runner sends back the result as a serialized Template Haskell AST (using GHC.Generics for the Binary instances). All Template Haskell functionality is supported, including recent additions for reifying modules and annotations. I still need to clean up and push the patches for the directory and process packages, but after that, the TH code can read/write files, run processes and interact with them and make network connections, all through node.js. Now since this approach is in no way specific to JavaScript, I was wondering if there's any interest in getting this functionality into GHC 7.10 for general cross compilation. The runner would be a native (target) program with dynamic libraries (or object files) being sent over to the target machine (or emulator) for the splices. Thanks to Andras Slemmer from Prezi who helped build the initial proof of concept (without reification) at BudHac. cheers, Luite [1] https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261… [2] https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812… [3] https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261… [4] https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812…

9 16

ghc, tls, gmp
by Joachim Breitner 05 Jul '14

05 Jul '14

Hi, in Debian, we have the (well-known) problem of linking against libraries using libgmp, in this case haskell-curl, which links against libcurl, which links against gnutls, which uses libgmp since the latest release: https://lists.debian.org/debian-haskell/2014/07/msg00000.html Are there any viable solutions to this problem that I might not be aware of? Are there any solutions to be expected in the near future? (My best idea so far is to use libcurl linked against openssl, but this causes licensing issues.) Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nomeata(a)debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F JID: nomeata(a)joachim-breitner.de | http://people.debian.org/~nomeata

1 0

GHC and Haskell-Platform on OpenBSD
by Matthias Kilian 04 Jul '14

04 Jul '14

Hi, I'd like to know wether anyone here is using GHC on OpenBSD *and* relying on the Haskell-Platform meta package for OpenBSD. If there's no need for the HP meta package, I could just start to update GHC and all related packages for OpenBSD, but if there are a lot of people who prefer to stick to the HP, I'd to wait until the official update of the HP. So, if you love running pkg_add haskell-platform on OpenBSD, please speak up. And if you don't care an just run pkg_add ghc please speak up too ;-) Ciao, Kili

1 0

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