- Glasgow-haskell-users

Re: Using extcore
by Tim Chevalier 02 Nov '11

02 Nov '11

On Wed, Nov 2, 2011 at 8:19 AM, Knut Halvor Skrede <khskrede(a)gmail.com> wrote: > Hi, > > I'm working on a project where I need to dump Core to an alternative format. > So I'm wondering if it is possible to use the ghc api to compile haskell to > core, > and then use the extcore package to make a representation of the result as a > Core module. That way I could simply traverse it and make whatever > representation > necessary, based on the Core language definition. It seems to me like the > extcore > package is only for parsing external-core files? I don't want to have to > dump core to > a file, then parse it back. I was unable to find any documentation on how to > do this. Hi Knut -- If I may ask, why don't you want to dump ext-core to a text file? I can understand if the answer is performance reasons, but I would strongly encourage you to start with this route in order to get a prototype working. It's much easier; at least the last time I tried to use it (which was over a year ago), the GHC API was quite imperative, and when you're just starting your implementation, it's easier not to worry about that sort of thing. If you go this route, you should be able to just use the extcore library out of the box. There is some minimal documentation as a README inside the extcore package (the version that's on hackage); if you have any questions that it doesn't answer, as is likely, feel free to ask me and CC the ghc-users mailing list (so that the answer will be public and searchable). Once you have a prototype working, if you find that intermediate file reading/parsing is a bottleneck, you can change what you have to use the API to generate Core in-process instead of generating an intermediate file with -fext-core. If you want to just use the GHC API from the start, I can't be as helpful there, because I haven't played with that part of GHC in a long time, and it's known to change quickly. People on the ghc-users mailing list may be able to help. Depending on what you want to do, you may not need to use the extcore library at all if you use the API. You can generate a Core module, as well as typecheck it (using Core Lint) only using API functions that are documented in the GHC API documentation. If you did need to use the extcore library together with the API, you would need to use one of the functions in the MkExternalCore module (which should also be part of the API) to explicitly convert GHC's internal Core into external Core. I haven't done this, but there's no reason in principle why it wouldn't work. If you do get results this way, and feel like helping out, you could add your procedure to the wiki: http://hackage.haskell.org/trac/ghc/wiki If you have any followup questions, please reply to me and CC the mailing list, as I don't always read the mailing list, but it's also good if replies are on the record. Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt “I cannot hide my anger to spare you guilt, nor hurt feelings, nor answering anger; for to do so insults and trivializes all our efforts. Guilt is not a response to anger; it is a response to one’s own actions or lack of action.” -- Audre Lorde

1 0

C, GCL interface
by Serge D. Mechveliani 01 Nov '11

01 Nov '11

Dear GHC developers, There is a computer algebra library called DoCon and written in Haskell (+GHC). And I am considering the possibility to extend it with many new methods by joining some open libraries written in C, C++, and in Gnu Common Lisp (GCL). 1. I have seen somewhere the announcement of the C library for numbers, algebraic numbers by Lenstra and may be, others. Is it real to design its interface to a Haskell program (DoCon), may be, by using some tools from GHC ? (which tools?) 2. There exists a great volum of math libraries written in Lisp-s, in particular, in GCL. I believe some of them have a free enough license. But how to interface to them? For example, is there possible an interpreter for GCL written in C ? If it is, then, may be, the GCL libraries can be interfaced by joining and applying this interpreter at the C data level? Also I have looked in the GCL page, and it was not clear where to ask about such GCL interpreter. I never tried these interface tricks and never looked into the Lisp design. Thank you in advance for your advice. ----------------- Serge Mechveliani mechvel(a)botik.ru

2 1

Linker flags --hash-style=both --no-copy-dt-needed-entries --as-needed
by Joachim Breitner 31 Oct '11

31 Oct '11

Dear GHC team, Ubuntu applies the following patch to the ghc package¹: diff -pruN 7.0.4-8/aclocal.m4 7.0.4-8ubuntu1/aclocal.m4 --- 7.0.4-8/aclocal.m4 2011-10-31 16:22:09.000000000 +0000 +++ 7.0.4-8ubuntu1/aclocal.m4 2011-10-31 16:22:20.000000000 +0000 @@ -109,6 +109,10 @@ AC_DEFUN([FPTOOLS_SET_C_LD_FLAGS], $4="$$4 -arch x86_64" $5="$$5 -m64" ;; + *-linux*) + $3="$$3 -Wl,--hash-style=both,--no-copy-dt-needed-entries,--as-needed" + $4="$$4 --hash-style=both --no-copy-dt-needed-entries --as-needed" + ;; esac # If gcc knows about the stack protector, turn it off. and it was requested² that this should be done in Debian as well. I generally feel uneasy diverging from upstream, as it could make debugging harder, so I’m contacting you first whether you might be interested in applying the change to ghc proper. I did not dig deep into the reason behind the patch, but http://wiki.debian.org/ToolChain/DSOLinking seems to give some reasons, and the author of the patch, Matthias Klose, is CCed. Greetings, Joachim ¹ http://patches.ubuntu.com/g/ghc/ghc_7.0.4-8ubuntu1.patch ² http://lists.debian.org/debian-haskell/2011/10/msg00066.html -- Joachim "nomeata" Breitner Debian Developer nomeata(a)debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nomeata(a)joachim-breitner.de | http://people.debian.org/~nomeata

1 0

Type error: Expected type: T. Actual type T ???
by Bas van Dijk 31 Oct '11

31 Oct '11

Hello, I'm working on a new design of monad-control[1]. However I get a type error I don't understand. Here's an isolated example: {-# LANGUAGE UnicodeSyntax, RankNTypes, TypeFamilies #-} class MonadTransControl t where type St t ∷ * → * liftControl ∷ Monad m ⇒ (Run t → m α) → t m α restore ∷ Monad o ⇒ St t γ → t o γ type Run t = ∀ n β. Monad n ⇒ t n β → n (St t β) foo :: (Monad m, MonadTransControl t) => (Run t -> m α) -> t m α foo f = liftControl f Type checking 'foo' this gives the following error: Couldn't match expected type `Run t' with actual type `Run t' Expected type: Run t -> m α Actual type: Run t -> m α In the first argument of `liftControl', namely `f' In the expression: liftControl f When I remove the type annotation of 'foo' the program type checks. But when I ask ghci the type of 'foo' it tells me it's the same type: > :t foo foo :: (Monad m, MonadTransControl t) => (Run t -> m α) -> t m α Is this a bug in GHC? I'm using ghc-7.2.1. Regards, Bas [1] http://hackage.haskell.org/package/monad-control

3 4

Errors building HEAD
by Johan Tibell 26 Oct '11

26 Oct '11

Hi, Trying to build HEAD from a clean tree I get: "/usr/bin/ghc" -H64m -O -fasm -package-conf libraries/bootstrapping.conf -package-name ghc-7.3 -hide-all-packages -i -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage1/build -icompiler/stage1/build/autogen -Icompiler/stage1/build -Icompiler/stage1/build/autogen -Icompiler/stage1 -Icompiler/../libraries/base/cbits -Icompiler/../libraries/base/include -Icompiler/. -Icompiler/parser -Icompiler/utils -optP-include -optPcompiler/stage1/build/autogen/cabal_macros.h -package Cabal-1.11.3 -package array-0.3.0.2 -package base-4.3.1.0 -package bin-package-db-0.0.0.0 -package bytestring-0.9.1.10 -package containers-0.4.0.0 -package directory-1.1.0.0 -package filepath-1.2.0.0 -package hoopl-3.8.7.2 -package hpc-0.5.1.0 -package old-time-1.0.0.6 -package process-1.0.1.5 -package unix-2.4.2.0 -Wall -fno-warn-name-shadowing -fno-warn-orphans -XHaskell98 -XCPP -XMagicHash -XUnboxedTuples -XPatternGuards -XForeignFunctionInterface -XEmptyDataDecls -XTypeSynonymInstances -XMultiParamTypeClasses -XFlexibleInstances -XRank2Types -XScopedTypeVariables -XDeriveDataTypeable -DSTAGE=1 -Rghc-timing -O -fasm -no-user-package-conf -rtsopts -odir compiler/stage1/build -hidir compiler/stage1/build -stubdir compiler/stage1/build -hisuf hi -osuf o -hcsuf hc -c compiler/prelude/PrelNames.lhs -o compiler/stage1/build/PrelNames.o <<ghc: 1246932544 bytes, 43 GCs, 9388809/19990512 avg/max bytes residency (5 samples), 83M in use, 0.00 INIT (0.00 elapsed), 0.85 MUT (0.97 elapsed), 0.25 GC (0.26 elapsed) :ghc>> make[1]: *** No rule to make target `libraries/Cabal/cabal/dist-boot/build/Distribution/Version.hi', needed by `compiler/stage1/build/PackageConfig.o'. Stop. make: *** [all] Error 2 Mac OS X 10.7.2 (not that I think it matters in this case). -- Johan

2 2

:kind broken in HEAD
by Sean Leather 25 Oct '11

25 Oct '11

It seems like :kind is broken in the HEAD ghci: *Main> :kind Maybe Top level: Expecting an ordinary type, but found a type of kind * -> * In a type expected by the context: Maybe *Main> Simon, could this be related to your change for :kind! ? Regards, Sean

2 1

Discussion about the ConstraintKinds extension
by bob zhang 22 Oct '11

22 Oct '11

Hi all, I have played quite a bit with the ConstraintKinds extension, pretty cool. But I found a problem which I thought would be made better, plz correct me if I am wrong take a contrived example, class C B => B a where here B :: * -> Constraint, I think this definition is reasonable, since B does not appears in the first position of the context. Previously, we require acyclic class declarations since we don't have ConstraintKinds extension but now since type class could be abstracted, I think the definition above should be ok. the ghc-manual cited the program below is valid class C a where {op :: D b => a -> b -> b} class C a => D a where { ... } I think there are no reasons to reject class C B => B where (and this style is pretty useful in some cases) ... B :: * -> Constraint C :: (*->Constraint) -> Constraint Any comments are welcome -- Best, bob

2 5

ANN: GhciExt 0.7
by Peter Hercek 20 Oct '11

20 Oct '11

I finally moved to GHC 7.0.3, a rather late update :) I updated GhciExt for it and if you want to script ghci commands a bit you can grab it as an example and use. It probably works well enough. I was lucky and did not use debugger a lot lately, so I'm not sure. http://www.hck.sk/users/peter/pub/ghciext-0.7.tar.gz It redefines some standard commands (like e.g. :break to output hit count) and adds some new commands (the most useful are probably :grep and :watch (conditional breakpoint)). Here is the list of the added commands: Prelude> :defs long :. <file> -- source commands from <file> :* <count> <cmd>... -- run <cmd> <count> times :x <cmd>... -- run <cmd> with stdout suppressed :output -- restore ghci output (stdout and stderr) back Restores stdout and stderr of ghci as it was during startup. You should not ever need this command. It is here only if something would go wrong in ghciExt and you need to recover (console) manually. :redir <var> <cmd>... -- execute <cmd> redirecting stdout to <var> :grep <args> < <cmd>... -- run grep <args> on <cmd> output Runs grep from your OS on the output of <cmd>. This means all the options of your OS grep are available. '<' separates grep options from the command. :find <cmd> [-]<var> -- step with <cmd> until <var> is found Prepend variable name with '-' to disable printing of its value. :locate <cmd> <bpArgs> -- step with <cmd> until location <bpArgs> is hit :repeat <cmd> <cond> -- repeat <cmd> until <cond> is true :inject <cc> <c> <sc> -- at location run <c> if <cc> and stop if <sc> There are two special identifiers which can be used in the breakpoint code (<c>) and the breakpoint stop condition (<sc>); but which are not usable in the breakpoint code condition (<cc>). These are: - ġė_BpId - macro name; translates to breakpoint id - ġė_HitCnt - macro name; translates to breakpoint hit count :strobe [&<c>] -- at location show hit count if <c> :monitor [&<c>] <e> -- :force expression <e> at location if <c> :watch <cond> <bpArgs> -- break at location <bpArgs> when <cond> is True :count [<R>]<N> [<bp>] -- count/stop execution at <bp> or query bp hits There are four ways how to use this command: - :count 0 <bp> - never stops; counts hits and extends trace history - :count N <bp> - stops when location <bp> is hit N-th time - :count RN <bp> - stops when hitCount@bp is in Ord relation R with N - :count N - shows hit count of a ghciExt breakpoint with number N. :class <classId> -- show class methods :defs [long] -- list user commands (possibly with long help) General information for all GhciExt commands: - Most arguments may be in quotation marks (to allow spaces in them). - Instead of a regular quotation mark, @x can be used to start a string argument too. In such a case the argument is finished when character x appears again after `@x' string. Use any character in place of x. - Most commands can have an end-line comment. The comment starts with this sequence: "d--", where d is the argument delimiter; i.e. it is '"', the x after '@' or whitespace based on the previous argument. - GhciExt calls :init any time GHCi may have cleared your top level symbols. Redefine :init to reintroduce the symbols you want always available. Prelude>

1 0

RE: FW: Two Proposals
by Simon Peyton-Jones 19 Oct '11

19 Oct '11

[adding ghc-users] It's not easy, Phil. Do you have any ideas? For the 'then' case the name of the function serves as the verb. One might say then take 4 or then takeWhile by salary > 40 For grouping one might like to say the same thing, such as then groupBy by salary but the typing rule is quite different, so we really need a different keyword. We chose the compound keyword "then group" to avoid needing a whole new keyword ("group" is treated specially only in tthis context). So you write then group by salary using groupBy Using this order of the pieces for the sorting case is harder. What would one say? "then process"? Like this? then process by salary > 40 using takeWhile Not very nice. One could use a new keyword for grouping "theng" say, thus: theng groupBy by salary But that is hardly beautiful either. So the current story is not great, but it's the best I could think of. Improvements welcome. Simon | -----Original Message----- | From: Philip Wadler [mailto:wadler@inf.ed.ac.uk] | Sent: 04 October 2011 18:15 | To: Simon Peyton-Jones; George Giorgidze | Subject: Re: FW: Two Proposals | | George, | | Nice proposal. I like the idea of symmetry, but don't at all like the | idea that f comes before e for 'then' but f comes after e for 'then | group'. Can you rethink it and come up with something even more | symmetric? | | Yours, -- P | | | On Tue, Oct 4, 2011 at 9:23 AM, Simon Peyton-Jones | <simonpj(a)microsoft.com> wrote: | > FYI | > | > -----Original Message----- | > From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell- | users-bounces(a)haskell.org] On Behalf Of George Giorgidze | > Sent: 30 September 2011 18:28 | > To: glasgow-haskell-users(a)haskell.org | > Subject: Two Proposals | > | > GHC Users, | > | > I would like to make to the following two proposals: | > * Eliminate the default grouping close from SQL-like comprehensions | > * Introduce a GHC extension for list literal overloading | > | > OK, let me start with the first proposal. | > | > Currently, the SQL-like comprehension notation (both in its list comprehension | and monad comprehension variants) features the following five clauses: | > | > then f | > then f by e | > then group by e | > then group using f | > then group by e using f | > | > The first two clauses are used for specifying transformations of type [a] -> [a] | (or Monad m => m a-> m a for monad comprehensions). The following three | clauses are used for specifying transformations of type [a] -> [[a]] (or Monad m, | Functor f => m a -> m (f a) for monad comprehensions). See [1] for further | details. | > | > Note that the third clause does not mention which function is used for grouping. | In this case GHC.Exts.groupWith function is used as a default for list | comprehensions and the mgroupWith function from the MonadGroup class is used | as a default for monad comprehensions. | > | > I would like to suggest to remove the third clause for the following reasons: | > * Currently the syntax is asymmetrical. Note that there is the default case for | the 'then group' clause and not for the 'then' clause. | > * In the current notation it is not clear which grouping function is used in the | default case | > * For many monads including lists it is not clear which function should be | selected as a default (e.g., the groupWith function also does sorting and it is not | clear to me why this should be the default) | > * Gets rid of the MonadGroup class. Currently the sole purpose of this class is to | introduce a default grouping function for monad comprehensions. | > * Explicit mention of the grouping function would make monad/list | comprehensions much easier to read by making it immediately apparent which | function is used for grouping. | > | > My second proposal is to introduce the OverloadedLists extension that overloads | list literals. See Section 5.2 in [1] for details. | > | > Basically the idea is to treat list literals like: | > | > [1,2,3] | > | > as | > | > fromList [1,2,3] | > | > where | > | > class IsList l where | > type Item l | > fromList :: [Item l] -> l | > | > In the following I give useful instances of the IsList class. | > | > instance IsList [a] where | > type Item [a] = a | > fromList = id | > | > instance (Ord a) => IsList (Set a) where | > type Item (Set a) = a | > fromList = Set.fromList | > | > instance (Ord k) => IsList (Map k v) where | > type Item (Map k v) = (k,v) | > fromList = Map.fromList | > | > instance IsList (IntMap v) where | > type Item (IntMap v) = (Int,v) | > fromList = IntMap.fromList | > | > instance IsList Text where | > type Item Text = Char | > fromList = Text.pack | > | > As you can see the extension would allow list literals to be used for sets, maps | and integer maps. In addition the suggested OverloadedLists extension would | subsume OverloadedStrings extension (see the instance for Text, for example). | Having said that, for now, I am not suggesting to remove the OverloadedStrings | extension as it appears to be widely used. | > | > This extension could also be used for giving data-parallel array literals instead of | the special syntax used currently. | > | > Unless there is a vocal opposition to the aforementioned two proposals, I would | like to implement them in GHC. Both changes appear to be straightforward to | implement. | > | > Thanks in advance for your feedback. | > | > Cheers, George | > | > [1] http://www-db.informatik.uni-tuebingen.de/files/giorgidze/haskell2011.pdf | > _______________________________________________ | > Glasgow-haskell-users mailing list | > Glasgow-haskell-users(a)haskell.org | > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users | > | > | > | | | | -- | .\ Philip Wadler, Professor of Theoretical Computer Science | ./\ School of Informatics, University of Edinburgh | / \ http://homepages.inf.ed.ac.uk/wadler/ | | The University of Edinburgh is a charitable body, registered in | Scotland, with registration number SC005336. |

3 3

Implementing a new Primop, stage1 panic
by Paul Monday 18 Oct '11

18 Oct '11

(Reposting since this got cross-posted sort of oddly and I wasn't subscribed yet) I'm having an odd problem as I try to define my own primop, it seems that some docs may be out of date with respect to all of the touch points for a simple primop addition. I've followed what the various wiki pages have to offer (primarily http://hackage.haskell.org/trac/ghc/wiki/AddingNewPrimitiveOperations and http://hackage.haskell.org/trac/ghc/wiki/Commentary/PrimOps) without success. I even unraveled my PrimOp to be, basically, an exact copy of another PrimOp without luck. The primop I'm attempting to add is now very, very simple and copies FloatAddOp exactly so there must be an additional file I have to modify before the primop is "completely" added. Here are my simple modifications: ./compiler/prelude/primops.txt.pp primop FloatVAddOp "plusFloatVec#" Dyadic Float# -> Float# -> Float# with commutable = True ./compiler/codeGen/CgPrimOp.hs translateOp FloatVAddOp = Just (MO_F_Add W32) The compiler error is below. I have the feeling that an interface is not being built somewhere … this must be a simple one but I can't find any references to this error anywhere … has anyone seen this one before????? "inplace/bin/ghc-stage1" -H64m -O0 -fasm -package-name ghc-7.3.20111007 -hide-all-packages -i -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage2/build -icompiler/stage2/build/autogen -Icompiler/stage2/build -Icompiler/stage2/build/autogen -Icompiler/../libffi/build/include -Icompiler/stage2 -Icompiler/../libraries/base/cbits -Icompiler/../libraries/base/include -Icompiler/. -Icompiler/parser -Icompiler/utils -optP-DGHCI -optP-include -optPcompiler/stage2/build/autogen/cabal_macros.h -package Cabal-1.11.2 -package array-0.3.0.3 -package base-4.4.0.0 -package bin-package-db-0.0.0.0 -package bytestring-0.9.2.0 -package containers-0.4.2.0 -package directory-1.1.0.1 -package filepath-1.2.0.1 -package hoopl-3.8.7.2 -package hpc-0.5.1.0 -package old-time-1.0.0.7 -package process-1.1.0.0 -package template-haskell-2.6.0.0 -package unix-2.5.0.0 -Wall -fno-warn-name-shadowing -fno-warn-orphans -XHaskell98 -XNondecreasingIndentation -XCPP -XMagicHash -XUnboxedTuples -XPatternGuards -XForeignFunctionInterface -XEmptyDataDecls -XTypeSynonymInstances -XMultiParamTypeClasses -XFlexibleInstances -XRank2Types -XScopedTypeVariables -XDeriveDataTypeable -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -O0 -fasm -no-user-package-conf -rtsopts -odir compiler/stage2/build -hidir compiler/stage2/build -stubdir compiler/stage2/build -hisuf hi -osuf o -hcsuf hc -c compiler/iface/BinIface.hs -o compiler/stage2/build/BinIface.o ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.3.20111007 for x86_64-unknown-linux): applyTypeToArgs ghc-prim:GHC.Prim.sizeofMutableArray#{(w) v 91V} [gid[PrimOp]] @ e{tv i4L2} [tv] ds{v i4Lc} [lid] i#{v i4Lg} [lid] forall a{tv 12} [tv]. ghc-prim:GHC.Prim.MutableArray#{(w) tc 31m} e{tv i4L2} [tv] a{tv 12} [tv] -> ghc-prim:GHC.Prim.Int#{(w) tc 3G} Paul Monday Parallel Scientific, LLC. paul.monday(a)parsci.com

3 3