- Glasgow-haskell-users

Re: [core libraries] Re: Tightening up on inferred type signatures
by Ganesh Sittampalam 30 Apr '14

30 Apr '14

On 23/04/2014 20:04, dm-list-haskell-libraries(a)scs.stanford.edu wrote: > Edward Kmett <ekmett(a)gmail.com> writes: > >> You can wind up in perfectly legitimate situations where the name for the >> type you are working with isn't in scope, but where you can write a >> combinator that would infer to have that type. I'd hate to lose that. >> >> It is admittedly of marginal utility at first glance, but there are some >> tricks that actually need it, and it can also arise if a type synonym >> expands to a type that isn't exported or brought into scope, so trying to >> push this line of reasoning too far I is possibly not too productive. > > Good point. In particular, it's not weird at all want to export type > synonyms on their own, particularly where ghost type parameters are used > to select between only a few cases. Consider something like this > (inspired by postgresql-orm): Is there an abstraction being protected by only exporting the type synonym in cases like this? Cheers, Ganesh

2 2

Fwd: Type/type class information in GHC plugin
by Shen Chen Xu 27 Apr '14

27 Apr '14

Hello everyone, I would like to write a GHC plugin which adds wrapper to functions. Say I have a function addWrapper :: Ord a => (a -> b) -> a -> b which is supposed to transform (assuming the argument is in the Ord class) foo = \ x -> ... into foo = addWrapper (\ x -> ...) This works fine if I'm only interested in wrapping functions of type Int -> Int, in which case I make addWrapper to also have type addWrapper :: (Int -> Int) -> Int -> Int and use mkCoreApp to apply addWrapper to the right hand side. However, if I want it to be polymorphic as described above, the transformed GHC Core for an Int -> Int function should look like foo = addHook @ GHC.Types.Int @ GHC.Types.Int GHC.Classes.$fOrdInt (\ x -> ...) My question is, given the right hand side of foo, how do I construct the type/type class information inside Core shown above? Cheers, Shen

2 1

Help with cast error
by Conal Elliott 24 Apr '14

24 Apr '14

I'd appreciate help with a cast-related Core Lint error I'm getting with a GHC plugin I'm working on: Argument value doesn't match argument type: Fun type: Enc (Vec ('S 'Z) Bool) ~ (Bool, ()) => EP (Enc (Vec ('S 'Z) Bool)) -> EP (Bool, ()) Arg type: ~R# (Enc (Vec ('S 'Z) Bool)) (Bool, ()) Arg: CO Sub (TFCo:R:EncVec[0] <'Z>_N <Bool>_N) ; (Sub TFCo:R:EncBool[0], Sub (TFCo:R:EncVec0[0] <Bool>_N))_R (I omitted the module prefixes for brevity.) Do I have a role wrong here, or maybe something more fundamental? I can easily supply more info if it'd help. Thanks, -- Conal

2 2

RE: [core libraries] Re: Tightening up on inferred type signatures
by Simon Peyton Jones 23 Apr '14

23 Apr '14

| Independent of language extensions, what about types and classes whose | names are not in scope. Is there an implicit "... if you import all | the relevant symbols" and the end of the rule? Good point. I'm honestly unsure how far to push this one! (It'd be relatively easy to check whether they were in scope and complain if not, but ...) Simon | -----Original Message----- | From: haskell-core-libraries(a)googlegroups.com [mailto:haskell-core- | libraries(a)googlegroups.com] On Behalf Of David Mazieres | Sent: 22 April 2014 00:41 | To: Simon Peyton Jones; Haskell Libraries (libraries(a)haskell.org) | core-libraries-committee(a)haskell.org; GHC users | Subject: [core libraries] Re: Tightening up on inferred type signatures | | Simon Peyton Jones <simonpj(a)microsoft.com> writes: | | > GHC generally obeys this rule | > | > * If GHC infers a type f::type, then it's OK for you to add a type | > signature saying exactly that. | | Independent of language extensions, what about types and classes whose | names are not in scope. Is there an implicit "... if you import all | the relevant symbols" and the end of the rule? | | David | | -- | You received this message because you are subscribed to the Google | Groups "haskell-core-libraries" group. | To unsubscribe from this group and stop receiving emails from it, send | an email to haskell-core-libraries+unsubscribe(a)googlegroups.com. | For more options, visit https://groups.google.com/d/optout.

2 1

testing 7.8.2
by Sergei Meshveliani 23 Apr '14

23 Apr '14

Dear GHC developers, I have tested ghc-7.8.2-src by making it by ghc-7.6.3 under Debian Linux. Then I have `made' my DoCon-2.12 application by ghc-7.8.2. It looks all right. For any occasion, here are some test results. Comparing it to ghc-7.4.1 shows the following. 1) The default context reduction stack (21) is not sufficient, so, I add -fcontext-stack=30 to the options. 2) The resulting libHSdocon-2.12.a is 1/10 larger (but the DoCon source is not the same, and it is, may be 1/100 larger). 3) The Main executable test size is almost the same. 4) The test running speed is the same. 5) The minimal -M memory setting for running the test is 4300 Kb against 2400 Kb of ghc-6.4.1. Regards, ------ Sergei

1 0

installing random-1.0.1.1
by Sergei Meshveliani 22 Apr '14

22 Apr '14

People, can you, please, explain me how to make the `random' package visible for GHC ? I have * installed haskell-platform-2013.2.0.0, * `made' ghc-7.8.2 from source by ghc-7.6.3, and run make configure under ghc-7.8.2 for my DoCon program. docon.cabal has ---------------------------------------- ... tested-with: GHC build-type: Simple build-depends: base >= 4 && < 5, containers >= 0.3 && <= 0.5.5.1, random >= 1.0 && < 1.2 . exposed-modules: ... extensions: TypeSynonymInstances UndecidableInstances FlexibleContexts FlexibleInstances MultiParamTypeClasses OverlappingInstances RecordWildCards NamedFieldPuns DoAndIfThenElse ... ----------------------------------------- make configure reports runghc Setup.hs configure --ghc --prefix=/home/mechvel/docon/2.12/docon/source/inst -v Configuring docon-2.12... Setup.hs: At least the following dependencies are missing: random >=1.0 && <1.2 I do cabal install random, and now ghc-pkg list shows ------------------------------------- /home/mechvel/ghc/7.8.2/inst0/lib/ghc-7.8.2/package.conf.d Cabal-1.18.1.3 ... containers-0.5.5.1 ... ghc-7.8.2 ... unix-2.7.0.1 /home/mechvel/.ghc/x86_64-linux-7.8.2/package.conf.d random-1.0.1.1 -------------------------------------- But make configure still does not find random. The Haskell Platform is installed in the system area, ghc-7.8.2 and random-1.0.1.1 are installed in my home. Maybe, I need to run `register random' with some appropriate arguments? Can you, please, advise? Thanks, ------ Sergei

2 1

Tightening up on inferred type signatures
by Simon Peyton Jones 21 Apr '14

21 Apr '14

Friends GHC generally obeys this rule * If GHC infers a type f::type, then it's OK for you to add a type signature saying exactly that. For example, it rejects inferred types that are ambiguous. I think this is a good property; it was certainly the source of many bug reports before inferred ambiguous types were rejected. However, up to now (including in 7.8) GHC hasn't followed this rule consistently. In particular, it will infer types like fold :: (Functor (PF a), Regular a) => (PF a b -> b) -> a -> b (where PF is a type family). If you write this as a type signature, GHC will insist on FlexibleContexts and TypeFamilies. So in https://ghc.haskell.org/trac/ghc/ticket/8883, Jan has made GHC check inferred types in the same way that it checks declared types, thus rejecting the above inferred type unless you give the language extensions. This makes the compiler more consistent. But it does mean that some code may be rejected that 7.8 accepts. This email is just a heads-up that you might want to compile your library with 7.10 (i.e. a snapshot of HEAD) well in advance. There will be other breaking changes of course; e.g Applicative will finally be a superclass of Monad, for example. Simon

3 2

Concrete syntax for open type kind?
by Conal Elliott 21 Apr '14

21 Apr '14

I see ‘#’ for unlifted and ‘?’ for open kinds in compiler/parser/Parser.y: akind :: { IfaceKind } : '*' { ifaceLiftedTypeKind } | '#' { ifaceUnliftedTypeKind } | '?' { ifaceOpenTypeKind } | '(' kind ')' { $2 } kind :: { IfaceKind } : akind { $1 } | akind '->' kind { ifaceArrow $1 $3 } However, I don’t know how to get GHC to accept ‘#’ or ‘?’ in a kind annotation. Are these kinds really available to source programs. I see that undefined has an open-kinded type: *Main> :i undefined undefined :: forall (a :: OpenKind). a -- Defined in ‘GHC.Err’ Looking in the GHC.Err source, I just see the following: undefined :: a undefined = error "Prelude.undefined" However, if I try similarly, q :: a q = error "q" I don’t see a similar type: *X> :i q q :: forall a. a -- Defined at ../test/X.hs:12:1 I don't know what kind 'a' has here, nor how to find out. -- Conal

3 6

Re: HSghc-prim-0.3.1.0.o: unknown symbol 'memcpy'
by Roman Cheplyaka 19 Apr '14

19 Apr '14

* M Farkas-Dyck <strake888(a)gmail.com> [2014-04-19 12:55:23-0500] > On 19/04/2014, Roman Cheplyaka <roma(a)ro-che.info> wrote: > > Don't know if it helps, but I think ghci loads the dynamic library, not the static one. > > I straced both the broken ghci on aforesaid system and a working ghci > on a glibc system and it loads bare .o files. Interesting. I thought that has changed in 7.8. I'd love to see an explanation from someone knowledgeable. Roman

1 0

Autocomplete command line options with GHC 7.8
by Jan Stolarek 16 Apr '14

16 Apr '14

Hi all, GHC 7.8 adds --show-options flag that prints all supported command line flags on standard output. This can be used to enable autocompletion of command line options for ghc in shells that support autocompletion. If you're using bash add this snippet to your ~/.bashrc file: <<<<<<<<<<<<< START # Autocomplete GHC commands _ghc() { local envs=`ghc --show-options` # get the word currently being completed local cur=${COMP_WORDS[$COMP_CWORD]} # the resulting completions should be put into this array COMPREPLY=( $( compgen -W "$envs" -- $cur ) ) } complete -F _ghc -o default ghc <<<<<<<<<<<< END Enjoy. Janek PS. I also added a wiki page: https://ghc.haskell.org/trac/ghc/wiki/AutocompleteGHCFlags Feel free to add instructions for other shells.

2 3