- Glasgow-haskell-users

GHC on OpenIndiana
by asyropoulos＠aol.com 28 Oct '12

28 Oct '12

Dear Developers, I am trying to compile the GHC on OpenIndiana (essentially Solaris 11). I follow the steps in http://www.haskell.org/ghc/docs/6.4.1/html/building/sec-porting-ghc.html#se… and here is what I get: $ ./distrib/hc-build --prefix=/opt/gnu/ghcb --enable-hc-boot *** Building compiler... checking for gfind... /usr/bin/gfind checking for sort... /opt/gnu/bin/sort checking for ghc... no checking build system type... i386-pc-solaris2.11 checking host system type... i386-pc-solaris2.11 checking target system type... i386-pc-solaris2.11 HOST: i386-pc-solaris2.11 Can't work out build platform Not e that configure.ac contains a section on Solaris: SOLARIS_BROKEN_SHLD=NO case $host in i386-*-solaris2) # here we go with the test MINOR=`uname -r|cut -d '.' -f 2-` if test "$MINOR" -lt "11"; then SOLARIS_BROKEN_SHLD=YES fi ;; esac For whatever the reason I "need to update configure.in to recognise the new architecture, and re-generate configure with autoreconf" but I have no idea what exactly to add. There is no template inside to help me. Could you please let me know what should I do to proceed? Thank you in advance for your help/suggestions. A.S. -- Apostolos Syropoulos Xanthi, Greece

3 2

RULES for ByteString are not fired
by Kazu Yamamoto 28 Oct '12

28 Oct '12

Hello, I seems to us (my friends and me) that term rewriting rules for ByteString are not fired in recent GHCs. 6.12.3 OK 7.0.4 NG 7.4.1 NG 7.6.1RC1 NG For example, with the example from this ticket http://hackage.haskell.org/trac/ghc/ticket/3703 results in as follows: % ghc -O -ddump-simpl-stats --make breakOn.hs 14 RuleFired 4 Class op showsPrec 2 Class op show 2 eqChar#->case 2 unpack 2 unpack-list 1 Class op == 1 Class op >> There is no ByteString rules. Is this a bug or intention? --Kazu {-# LANGUAGE OverloadedStrings #-} import qualified Data.ByteString.Char8 as B main :: IO () main = do let string1 = B.pack "This is a string" string2 = B.pack "This is another string" print (breakOn ' ' string1) print (breakOn ' ' string2) breakOn :: Char -> B.ByteString -> (B.ByteString, B.ByteString) breakOn c = B.break (c==)

3 2

ghc: panic! (the 'impossible' happened)
by José Romildo Malaquias 28 Oct '12

28 Oct '12

Hello. Today I wrote a small program to experiment with the Applicative class. The program is supposed to use an "applicative reader", similar to a "monad reader", to evaluate arithmetic expressions. But when compiling the program with ghc-7.6.1, I get the following message: $ ghc --make applicative-eval [1 of 1] Compiling Main ( applicative-eval.hs, applicative-eval.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.6.1 for x86_64-unknown-linux): expectJust cpeBody:collect_args Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug If the line eval (Let s a b) = \m -> eval b ((s,eval a m):m) is commented out, the program compiles without problems. Is this a known issue with the compiler? The source code is attached. Romildo

3 3

Re: [Haskell-cafe] Problems translating Conor McBride's talk into Haskell + DataKind + KindPoly
by José Pedro Magalhães 26 Oct '12

26 Oct '12

Hi, Please use GHC 7.6 for experimenting with PolyKinds/DataKinds; the implementation in 7.4 was not fully complete. Your code compiles fine in 7.6. Cheers, Pedro On Fri, Oct 26, 2012 at 3:10 AM, Ahn, Ki Yung <kyagrd(a)gmail.com> wrote: > Promotion works for user defined lists such as > > data List a = Nil | Cons a (List a) > > And, if I use (List Bool) instead of [Bool] everything works out. > It's only the Haskell list type constructor [] is being a problem. > > In the "Giving Haskell a promotion" paper, it says that Haskell lists are > "natively promoted". I believe this means that it is treated specially > somehow. I don't know how it is implemented but what GHC 7.4.1 does > specially for Haskell lists has some problems. So, it's clearly not a > limitation of DataKind and PolyKind extension, but that special routine for > [] is the issue. > > I might have to write bug report. > > > On 2012년 10월 25일 18:07, Ahn, Ki Yung wrote: > >> Most part of Conor's talk at ICFP, until just before the last stage >> where he heavily uses true value dependency for compiler correctness all >> the code seemed to be able to translate into Haskell with the new hot >> DataKinds and PolyKinds extension. >> >> I tried it in GHC 7.4.1 and it was possible to do it, but I got stuck >> and I had to make the generic list structure mono-kinded with kind >> signatures rather not use the PolyKinds extension. >> >> I wonder if this is just a but of GHC 7.4.1's implementation of >> PolyKinds, or a limitation of the DataKind design. >> >> I attached a literate Haskell script with this message that illustrates >> this problem. >> >> Thanks in advance for any comments including whether it runs in later >> versions or still has problems, and discussions about the DataKinds and >> PolyKinds extension. >> >> Ki Yung >> >> >> ______________________________**_________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://www.haskell.org/**mailman/listinfo/haskell-cafe<http://www.haskell.org/mailman/listinfo/haskell-cafe> >> > > > > ______________________________**_________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/**mailman/listinfo/haskell-cafe<http://www.haskell.org/mailman/listinfo/haskell-cafe> >

1 0

Proposal: EPHEMERAL pragma
by José Pedro Magalhães 25 Oct '12

25 Oct '12

Hi all, Following up on a chat with Simon Peyton Jones at ICFP, I would like to discuss the possible introduction of a EPHEMERAL pragma. For example: {-# EPHEMERAL Rep #-} > data Rep = ... > This pragma would indicate that the programmer intends the Rep datatype not to be present in the final generated core code. Its proposed semantics are the following: 1. Make the compiler very keen to inline any functions that produce or consume Rep. 2. If Rep is exported, make all functions that operate on Rep INLINABLE (that is, make their code available for inlining in other modules). 3. Emit a warning if the generated core code still contains uses of Rep. My main use case for such a pragma is in the generic representation of datatypes in GHC.Generics. It's clear that we don't want sums and products lying around in user code, and in most cases we can get rid of them by inlining aggressively. Hopefully such a pragma can simplify or entirely replace the use of INLINE/INLINABLE pragmas in some cases. However, I'm not sure how well this can work in practice. Regarding (3), for instance, it's clear that functions that operate on Rep will be around in the final core code; perhaps only functions which do not directly produce or consume Rep, yet end up having values of Rep within them, should trigger a warning. (1) is hard to do well, in general. In particular when there are rewriting rules involving values of Rep, or functions that produce/consume Rep, the order in which they are inlined might affect the elimination of Rep values. In any case, I thought I'd share this with this list, in the hope to get feedback regarding how to improve the inliner (and the feedback programmers get regarding inlining). Cheers, Pedro

8 8

GHC compiling shared library linking problem
by Richard Zetterberg 22 Oct '12

22 Oct '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello This is the first time I'm mailing to this list, so I hope I have come to the right place. The problem I have is that I get a linker error when compiling a shared library with GHC. This problem occurred after I updated GHC from 7.0.3 to 7.4.1. Here is the error itself: /usr/bin/ld: ../src/Shared.so relocation R_X86_64_32S against `ghczmprim_GHCziTypes_ZC_con_info` can not be used when making a shared object; recompile with -fPIC ../src/Shared.so: could not read symbols: Bad value collect2: error: ld returned 1 exit status Here is the ghc command: ghc -O2 --make -no-hs-main -optl '-shared' -optc '-DMODULE=Shared' - - -o ../bin/pet_assembler_core.so Shared ../src/shared/module_init.c - - -i../src/; Shared.hs is the file where I specify the interface for the library, it only has one function: 1 {-# LANGUAGE ForeignFunctionInterface #-} 2 3 module Shared where 4 5 import qualified Data.ByteString as BS 6 import Foreign.Ptr (Ptr) 7 import Foreign.Storable (poke) 8 import Foreign.Marshal.Utils (copyBytes) 9 import Foreign.Marshal.Alloc (mallocBytes) 10 import Foreign.C.Types (CSize, CChar) 11 import Foreign.C.String 12 import Data.ByteString.Unsafe (unsafeUseAsCStringLen) 13 import Assembly.Data 14 import qualified Assembly as ASM 15 16 type PPString = Ptr (Ptr CChar) 17 type PSize = Ptr CSize 18 19 foreign export ccall assemble :: PPString -> PSize -> CString -> IO Int And the module_init.c contains initialization of the module: 1 #define CAT(a,b) XCAT(a,b) 2 #define XCAT(a,b) a ## b 3 #define STR(a) XSTR(a) 4 #define XSTR(a) #a 5 6 #include <HsFFI.h> 7 8 extern void CAT(__stginit_, MODULE)(void); 9 10 static void library_init(void) __attribute__((constructor)); 11 static void library_init(void) 12 { 13 static char *argv[] = { STR(MODULE) ".so", 0 }, **argv_ = argv; 14 static int argc = 1; 15 16 hs_init(&argc, &argv_); 17 hs_add_root(CAT(__stginit_, MODULE)); 18 } 19 20 static void library_exit(void) __attribute__((destructor)); 21 static void library_exit(void) 22 { 23 hs_exit(); 24 } Information about the system: Linux 2.6.32-5-amd64 Debian 6.0.6 GHC 7.4.1 GCC 4.7.2 GNU ld 2.22 So the question is, what could it be? Have I missed something? Or should I report this as a bug? Best regards Richard Zetterberg -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQfA6/AAoJEP99n2Mvs+maKp4P/iznMCLd73Os0tOarCHcyiK4 b96Zi1ibD5jqiojAWseoX3xCj4uNKIGy20GzDKRS5gZi3rXkw+wuCyLfj/RetrbN 8sy3RNVpbNulwRn/0HnFDOINpAOlO/y+6l45YcfhTSJGRCR0Hv7yhhlHbcyezZ+G i4UORXygc2TnCVL1Vc0RdmmPOAehfmla1oo1bwmmQ6l6hhdrHJpo0jVukN+Dy+qv enGF4Z9IMVjtgZizmEHmFA9UbMpKDDCXHKTsCSliSKErx4ebz0VeEkCCXWXE9c5M 0sUkAmDkiV8+CJ+RPJBMjIDihuothQ4Hpt2ZWBXo6I4D7J9MkkW8Qe9kmwvzLQQO d7+w2qsHkI9x3bSnH6D3Co+crgqUnHf2OGDI8Hhbc2Ra82wcobCxHyxNWWAa8P07 q3/cu9xNDceTRnJ0tx9R2e9qByp5+eOAhtabNcX3yTsWWKSD2P0FNC2sjxMH/Psz mWIDAiFfOGrKRAilm3CxokeX5k+tPMP+piU3b2WNPEJHaS/Hgl9Xl4eHi/DRnzJ7 9Fu09ynoB3yllPyIzLijXdOrwaTt7qWwxt48D1TwX+hl7CRxwOCFJKXyeZoRiSTc D+Lbts5ST5skqnRHiQNxdrCODCvGoLhUJTDHEyVm3b9fFstkpR7tQc3nVywJ9DFH p9Sh9UdEAc9a1URkCXS4 =ZU3J -----END PGP SIGNATURE-----

3 4

divRem by `-' performance
by Serge D. Mechveliani 18 Oct '12

18 Oct '12

People, consider the following contrived program for division with remainder: ---------------------------------------------------------------- qRem :: Int -> Int -> (Int, Int) qRem m n = if m < 0 || n <= 0 then error "\nwrong arguments in qRem.\n" else qRem' 0 m where qRem' q r = if r < n then (q, r) else qRem' (succ q) (r - n) main = putStr $ shows (qRem n 5) "\n" where e = 25 n = 2^e ---------------------------------------------------------------- Compilation in ghc-7.4.1 : ghc --make -O -rtsopts Main Rinning: time ./Main +RTS -K.. -M.. -RTS For e = 25, it takes the minimum of -K80m -M280m (on my Linux Debian machine). Is not this memory eagerness strange? Regards, Sergei

3 7

RE: PolyKind issue in GHC 7.6.1rc1: How to make a kind a functional dependency?
by Simon Peyton-Jones 16 Oct '12

16 Oct '12

I'm afraid I've rather lost track of this thread. Would someone care to summarise, on a wiki page perhaps? I think the story is: * Inspired by Nick's idea, Iavor and Pedro have converged on a single, type-family-based style for defining singletons. * This style no longer requires Any to be a data type, so I can turn it back into a type family, which is a Good Thing because it paves the way for an eta rule. RSVP and I'll do that. * Iavor mutters about sketchiness, but I'm not sure what that means specifically. * I'm not sure how, it at all, it affects Richard's singletons paper Simon From: Iavor Diatchki [mailto:diatchki@galois.com] Sent: 12 October 2012 21:11 To: Richard Eisenberg Cc: Nicolas Frisby; Simon Peyton-Jones; Stephanie Weirich; Conor McBride; glasgow-haskell-users(a)haskell.org Subject: Re: PolyKind issue in GHC 7.6.1rc1: How to make a kind a functional dependency? Hello, (summary: I think Nick's idea works for what's in GHC.TypeLits, and it would allow us to switch from `Any` as a constructor to `Any` as a function.) On 10/11/2012 08:47 PM, Richard Eisenberg wrote: Iavor and I collaborated on the design of the building blocks of singleton types, as we wanted our work to be interoperable. A recent scan through TypeLits tells me, though, that somewhere along the way, our designs diverged a bit. Somewhere on the to-do list is to re-unify the interfaces, and actually just to import TypeLits into Data.Singletons so the definitions are one and the same. Iavor, I'm happy to talk about the details if you are. The module GHC.TypeLits hasn't really changed much since last we talked (the Nat1 type is new, but that's only for working with type-level naturals and unrelated to this discussion). I added the SingE class so that my work is compatible with Richard's (a simple newtype suffices if we are only interested in working with singletons for type-level literals). So we should certainly make the two compatible again, let me know what needs to change. I was just playing around with Nick's idea and here is my version of the code, which loads fine (but as I discuss in point 2 bellow I think it is a bit sketchy...) import GHC.TypeLits hiding (SingE(..), Kind) import qualified GHC.TypeLits as Old data Kind (k :: *) -- discuessed in point 2 bellow class SingE (any :: Kind k) rep | any -> rep where fromSing :: Sing (a :: k) -> rep instance SingE (any :: Kind Nat) Integer where fromSing = Old.fromSing instance SingE (any :: Kind Symbol) String where fromSing = Old.fromSing I think that there are two interesting points about this code: 1. It is important that the instances are polymorphic because this tells GHC that it is allowed to use the instance in any context as long as the kinds match, regardless of the actual type. Note that this is not the case if we write the instance using the singleton member of the proxy kind: data KindProxy (k :: *) = KindProxy instance SingE ('KindProxy :: KindProxy Nat) Integer where fromSing (SNat n) = n Such instances would only work if GHC could see that the type is 'KindProxy so if we have a type variable of the correct kind, the instance would not reduce. This is related to the eta-expansion issue---if we eliminated `Any`, then GHC could perform a kind-based improvement to deduce that the type variable must be equal to `KindProxy`, because this is the only type with the correct kind. 2. As Nick noticed, we are not doing any fancy type computing in the class, so we don't actually need any KindProxy elements---we are just doing overloading based on a kind rather than a type. To emphasize this I made Kind an empty type/kind and GHC is still happy: instances are resolved as intended. But... `Kind` has no elements so what are the instances applied to? The only reason this works is that GHC has defaulted the instances to use `Any`. To me this seems a bit sketchy. So what to do? Changing the code in this style (using the normal non-empty proxy) makes sense because I think that it would allow us to change `Any` into a type function rather than a type constructor, like Simon did and un-did recently. The reason I think this will work is because now there will be no uses of `Any` in the definitions of the instances, it will only appear in the uses of the instances. Furthermore, I think it makes sense for GHC to check that for each use of the type function `Any`, the kind where it is used is non-empty. I'm not sure how easy it would be to implement that, so maybe we can deal with it later. -Iavor

3 2

Re: Constructing TH types
by Eric M. Pashman 16 Oct '12

16 Oct '12

Nicolas, thanks for the welcome, and thanks for pointing out the additional 'Type' constructors! I'd looked over the available constructors, but apparently not very well. The 'ListT', 'TupleT', 'ArrowT', etc., constructors are precisely what I need to make this work in a straightforward fashion. So I don't actually have a problem making the right 'Name' value, just a problem reading the TH source. Well, that's that. ... Many thanks, Eric On Oct 7, 2012, at 24:22 , Nicolas Frisby <nicolas.frisby(a)gmail.com> wrote: > On Sat, Oct 6, 2012 at 2:24 PM, Eric M. Pashman <eric.pashman(a)gmail.com> wrote: >> Hello, >> >> I'm using Template Haskell (which I've just begun to learn) to do "stanamic" type-checking. Basically I'm just converting 'TypeRep' and 'TyCon' values (from 'Data.Typeable') into Template Haskell's representation (i.e., values of the 'Type' datatype) and splicing them as type signatures in code where compile-time type inference is otherwise impossible. > > Hi Eric. I'm going to try to answer each of your questions below, but > it's not entirely clear to me what you are trying to do. If you can > provide more context, we might be able to give better answers or > perhaps suggest alternative approaches. > >> My first thought was simply to make a TH 'Name' from the 'show' representation of a 'TypeRep', and turn that into a 'Type': >> >> toType :: TypeRep -> Type >> toType = ConT . mkName . show >> >> This works for simple, atomic types like 'Int', but it chokes on compound types (I mean those with a type parameter, e.g. 'Maybe Int'.), for reasons I don't quite understand. > > If I fire up ghci and enter the following > > Prelude> :type Language.Haskell.TH.ConT > > I get back (roughly) the answer: ConT :: Name -> Type > > In particular, note that the argument to ConT is a name. Your code > indeed builds a name, but, in your example, it builds the invalid name > "Maybe Int". When I splice in the resulting type (ConT (mkName "Maybe > Int")), I get the error message > > Not in scope: type constructor or class `Maybe Int' > > ConT is only for a single named type; it cannot (by itself) represent > general types. Does that explanation get the big picture across? > > In particular, it cannot (by itself) represent an applications of one > named type to another. The type "Maybe Int" can be correctly > represented as ConT (mkName "Maybe") `AppT` ConT (mkName "Int"). Or, > even better, as ConT ''Maybe `AppT` ConT ''Int. Those ''s are both two > occurrences of single quotes — very handy but less known TH syntax. > >> So I tried this instead: >> >> toType tr = foldr (flip AppT . toType) (tcToType tc) trs where >> (tc, trs) = splitTyConApp tr >> >> tcToType :: TyCon -> Type >> tcToType = ConT . mkName . show >> >> This works for both simple types and compound types made from standard prefix type-constructors, but it breaks on sugared constructors like '[]'; a 'TypeRep' for, say, '[Int]' gets turned into an invalid type that spliced in as '[] Int'. >> >> Basically I don't quite understand how 'Name' construction and binding works. Is there a better way to make a 'Name' that will work with sugared type constructors, or do I have to special-case them while doing something like the above? (If so, what are all the special cases? Anything beyond lists and tuples?) > > Someone else can surely better explain Name construction and binding. > I recall there being subtleties, but instead of internalizing them, I > have been fortunate in my needs to be able to avoid mkName altogether > (via the ' and '' syntax). It sounds like you might actually require > it for you needs though. Hopefully someone else chimes in. > > Without more context, I'm not seeing an obviously more robust way that > will suite your needs. > > One way to see which special cases there are is to fire up ghci and > look at the constructors of the Type type. > > Prelude> :info Language.Haskell.TH.Type > data Type > = ForallT [TyVarBndr] Cxt Type > | AppT Type Type > | SigT Type Kind > | VarT Name > | ConT Name > | PromotedT Name > | TupleT Int > | UnboxedTupleT Int > | ArrowT > | ListT > | PromotedTupleT Int > | PromotedNilT > | PromotedConsT > | StarT > | ConstraintT > | LitT TyLit > > There are some fancier things in these constructors like support for > universal quantification and promotion, but the three constructors > that I'm guessing you're most likely to be interested in as special > cases are TupleT, ArrowT, and ListT. These are all pretty much > pairwise interchangable, eg ArrowT for (ConT ''(GHC.Prim.->)) and > ListT for (ConT ''[]). And unless my experience is out-of-date with > respect to this now, sometimes TupleT doesn't always show up instead > of a type like (ConT ''(GHC.Tuple.(,,,))). > > HTH. > >> >> Alternative approaches and general tips and hints are welcome as well. I'm fairly new to Haskell in general. > > Welcome, enjoy, and good luck! > >> >> Regards, >> >> Eric >> >> >> PS: To compile the code above, you just need these imports: >> >> import Language.Haskell.TH >> import Data.Typeable (TyCon, TypeRep, splitTyConApp) >> >> Here are some test cases: >> >> import Data.Typeable (typeOf) >> >> tr0 = typeOf (undefined :: Int) -- Simple >> tr1 = typeOf (undefined :: Maybe Int) -- Compound, infix >> tr = typeOf (undefined :: [Int]) -- Compound, sugared >> >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users(a)haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

3 4

PolyKind issue in GHC 7.6.1rc1: How to make a kind a functional dependency?
by Edward Kmett 12 Oct '12

12 Oct '12

If I define the following {-# LANGUAGE FunctionalDependencies, GADTs, KindSignatures, MultiParamTypeClasses, PolyKinds, RankNTypes, TypeOperators, DefaultSignatures, DataKinds, FlexibleInstances, UndecidableInstances #-} module Indexed.Test where class IMonad (m :: (k -> *) -> k -> *) where ireturn :: a x -> m a x infixr 5 :- data Thrist :: ((i,i) -> *) -> (i,i) -> * where Nil :: Thrist a '(i,i) (:-) :: a '(i,j) -> Thrist a '(j,k) -> Thrist a '(i,k) instance IMonad Thrist where ireturn a = a :- Nil Then 'ireturn' complains (correctly) that it can't match the k with the kind (i,i). The reason it can't is because when you look at the resulting signature for the MPTC it generates it looks like class IMonad k m where ireturn :: a x -> m a x However, there doesn't appear to be a way to say that the kind k should be determined by m. I tried doing: class IMonad (m :: (k -> *) -> k -> *) | m -> k where ireturn :: a x -> m a x Surprisingly (to me) this compiles and generates the correct constraints for IMonad: ghci> :set -XPolyKinds -XKindSignatures -XFunctionalDependencies -XDataKinds -XGADTs ghci> class IMonad (m :: (k -> *) -> k -> *) | m -> k where ireturn :: a x -> m a x ghci> :info IMonad class IMonad k m | m -> k where ireturn :: a x -> m a x But when I add ghci> :{ Prelude| data Thrist :: ((i,i) -> *) -> (i,i) -> * where Prelude| Nil :: Thrist a '(i,i) Prelude| (:-) :: a '(i,j) -> Thrist a '(j,k) -> Thrist a '(i,k) Prelude| :} and attempt to introduce the instance, I crash: ghci> instance IMonad Thrist where ireturn a = a :- Nil ghc: panic! (the 'impossible' happened) (GHC version 7.6.0.20120810 for x86_64-apple-darwin): lookupVarEnv_NF: Nothing Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Moreover, attempting to compile them in separate modules leads to a different issue. Within the module, IMonad has a type that includes the kind k and the constraint on it from m. But from the other module, :info shows no such constraint, and the above code again fails to typecheck, but upon trying to recompile, when GHC goes to load the IMonad instance from the core file, it panicks again differently about references to a variable not present in the core. Is there any way to make such a constraint that determines a kind from a type parameter in GHC 7.6 at this time? I tried the Kind hack used in GHC.TypeLits, but it doesn't seem to be applicable to this situation. -Edward

9 37