- Glasgow-haskell-users

RE: [Haskell-cafe] Template Haskell very wordy w/r/t Decs and Types
by Simon Peyton-Jones 28 May '09

28 May '09

You already have splicing for top level decls. Splicing for local decls is a whole different ball game because it brings new *binders* into scope. For example f = ...g... g = let $(foo) in ...f... Is the 'f' inside 'g' the same 'f' as the one bound at top level? Not necessarily, because $(foo) might bind f. So I can't even do dependency analysis to figure out whether f and g are mutually recursive! It gets harder if $(foo) mentions 'f'; and if the definition of 'f' has a declaration splice too. So splicing local decls introduces a new raft of questions whose answers are not obvious, and that might require some substantial structural rearrangement of GHC. In particular to the "rename and then typecheck" strategy. It's very similar to reason that we don't allow splices in patterns. Bottom line: my nose tells me this is a swamp and I'm steering clear of it for now. Simon From: Matt Morrow [mailto:moonpatio@gmail.com] Sent: 28 May 2009 00:08 To: Simon Peyton-Jones Cc: Ross Mellgren; Haskell Cafe; GHC users Subject: Re: [Haskell-cafe] Template Haskell very wordy w/r/t Decs and Types Spectacular! How difficult would it be to implement splicing in decls? I'm interested in having a go at it, and it seems like a perfect time since I can cheat off the fresh diff. In particular I'd love to be able to do stuff like this (without the current vicious hackery i'm using) (and granted, where i'm splicing is somewhat willy-nilly, but some approximation of this): ----------------------------------------------------------------------------- {-# LANGUAGE TemplateHaskell, QuasiQuotes #-} module DecTest where import HsDec import Data.List import DecTestBoot import Language.Haskell.TH.Lib import Language.Haskell.TH.Syntax import Language.Haskell.Meta.Utils bootQ :: Q [Dec] bootQ = bootQFunct primQStruct primQStruct = (''[] ,(conT ''[] `appT`) ,[|[]|] ,[|null|] ,[|undefined|] ,[|union|] ,[|undefined|] ,[|undefined|]) bootQFunct (primN :: Name ,primQ :: TypeQ -> TypeQ -- exists q. forall a. a -> q a ,emptyQ :: ExpQ -- Q a ,isEmptyQ :: ExpQ -- q a -> Bool ,insertQ :: ExpQ -- Int -> a -> q a -> q a ,mergeQ :: ExpQ -- q a -> q a -> q a ,findMinQ :: ExpQ -- q a -> Maybe (Int, a) ,deleteMinQ :: ExpQ) -- q a -> q a = do n <- newName "a" let primT = varT primN a = varT n [$dec| data BootQ $(a) = Nil | Node {-# UNPACK #-} !Int $(a) ($(primT) (BootQ $(a))) deriving(Eq,Ord) empty :: BootQ $(a) isEmpty :: BootQ $(a) -> Bool insert :: Int -> $(a) -> BootQ $(a) -> BootQ $(a) merge :: BootQ $(a) -> BootQ $(a) -> BootQ $(a) findMin :: BootQ $(a) -> Maybe (Int, $(a)) deleteMin :: BootQ $(a) -> BootQ $(a) empty = Nil isEmpty Nil = True isEmpty _ = False findMin Nil = Nothing findMin (Node n x _) = Just (n, x) insert n x q = merge (Node n x $(emptyQ)) q merge (Node n1 x1 q1) (Node n2 x2 q2) | n1 <= n2 = Node n1 x1 ($(insertQ) n2 (Node n2 x2 q2) q1) | otherwise = Node n2 x2 ($(insertQ) n1 (Node n1 x1 q1) q2) merge Nil q = q merge q Nil = q deleteMin Nil = Nil deleteMin (Node _ _ q) = case $(findMinQ) q of Nothing -> Nil Just (_, Node m y q1) -> let q2 = $(deleteMinQ) q in Node m y ($(mergeQ) q1 q2) |]

1 0

RE: [Haskell-cafe] Template Haskell very wordy w/r/t Decs and Types
by Simon Peyton-Jones 27 May '09

27 May '09

Folks Quite a few people have asked for splices in Template Haskell *types*, and I have finally gotten around to implementing them. So now you can write things like instance Binary $(blah blah) where ... or f :: $(wubble bubble) -> Int as requested, for example, in the message below. Give it a whirl. You need the HEAD; in a day or two you should find binary snapshots if you don't want to build from source. Simon PS: Note that you (still) cannot write a splice in a *binding* position. Thus you can't write f $(blah blah) = e or data T $(blah blah) = MkT Int I don't intend to change this; see the commentary at http://hackage.haskell.org/trac/ghc/ticket/1476 | -----Original Message----- | From: haskell-cafe-bounces(a)haskell.org [mailto:haskell-cafe-bounces@haskell.org] On | Behalf Of Ross Mellgren | Sent: 25 January 2009 19:55 | To: Haskell Cafe | Subject: [Haskell-cafe] Template Haskell very wordy w/r/t Decs and Types | | Hi all, | | I'm writing a small module that exposes a template haskell splice that | takes a (very simplified) C struct definition and builds: | | - A data type definition, | - an instance for Data.Binary.Binary, | - and optionally a pretty print function for it | | However, it seems to do this I have to write a bunch of really ugly | code that builds up the TH data structures "by hand" because quoting | only works with splices for expressions, or so it seems. | | For example, to generate the binary instance I have this code: | | import qualified Language.Haskell.TH as TH | | -- tyname is the name of the data type I've already created, as a | TH.Name | -- tempnames is a list of temporary variable names that are used in | lambda patterns | -- fields is a list of tuples describing each field | -- makeGetExp recursively builds a monadic computation consisting | mostly of Binary.getWord32be >>= \ tempvar -> ... | | binaryInstDec <- liftM (TH.InstanceD [] (TH.AppT (TH.ConT $ | TH.mkName "Data.Binary.Binary") (TH.ConT tyname))) | [d| get = $(makeGetExp (reverse $ zip | fields tempnames) returnExp) | put = undefined |] | | I'd really rather write: | | binaryInstDec <- [d| | instance Binary.Binary $(tyname) where | get = $(makeGetExp (reverse $ zip fields tempnames) | returnExp) | put = undefined |] | | But GHC gives me a syntax error on the tyname splice. The docs seem to | indicate this is the way it is -- that splices in type locations is | plain not implemented. | | My question is whether or not this is just the way it is, and people | writing TH declaration splices tend to have to start manually | assembling a bunch of it, or is there some trick I've missed? Perhaps | even better are there some tricks that people tend to use to make this | less painful? | | I did try using some of the lowercased monadic constructors in | Language.Haskell.TH.Lib but I didn't seem to get anything more succint | out of it.

1 0

Re: mtl and network packages in GHC 6.10.3.*
by Johan Tibell 27 May '09

27 May '09

I'll look into it later today when I have access to a Windows install. On May 27, 2009 3:33 AM, "Neil Mitchell" <ndmitchell(a)gmail.com> wrote: Hi, I just downloaded the Windows snapshot of 6.10.3.20090526, and found that mtl and network don't seem to be included. $ ghc-pkg list c:/ghc/ghc-6.10.3.20090526\package.conf: Cabal-1.6.0.1, Cabal-1.6.0.3, Win32-2.2.0.0, array-0.2.0.0, base-3.0.3.1, base-4.1.0.0, bytestring-0.9.1.4, containers-0.2.0.1, directory-1.0.0.3, extensible-exceptions-0.1.1.0, filepath-1.1.0.2, (ghc-6.10.3.20090526), ghc-prim-0.1.0.0, haddock-2.4.2, haskell98-1.0.1.0, hpc-0.5.0.3, integer-0.1.0.1, old-locale-1.0.0.1, old-time-1.0.0.2, packedstring-0.1.0.1, pretty-1.0.1.0, process-1.0.1.1, random-1.0.0.1, rts-1.0, syb-0.1.0.1, template-haskell-2.3.0.1, time-1.1.2.4 In addition, I can't install network under Cygwin, Mingw, or the Windows command line. Here are the errors from Cygwin: Preprocessing library network-2.2.1.2... In file included from Network\BSD.hsc:17: include/HsNet.h:78:22: sys/uio.h: No such file or directory include/HsNet.h:81:25: sys/socket.h: No such file or directory include/HsNet.h:84:26: netinet/tcp.h: No such file or directory include/HsNet.h:87:25: netinet/in.h: No such file or directory include/HsNet.h:90:21: sys/un.h: No such file or directory include/HsNet.h:93:24: arpa/inet.h: No such file or directory include/HsNet.h:96:19: netdb.h: No such file or directory In file included from Network\BSD.hsc:17: include/HsNet.h:138: error: syntax error before "addr" include/HsNet.h: In function `my_inet_ntoa': include/HsNet.h:146: error: storage size of 'a' isn't known include/HsNet.h:147: error: `addr' undeclared (first use in this function) include/HsNet.h:147: error: (Each undeclared identifier is reported only once include/HsNet.h:147: error: for each function it appears in.) include/HsNet.h:148: warning: return makes pointer from integer without a cast Network\BSD.hsc: In function `main': Network\BSD.hsc:145: error: invalid application of `sizeof' to incomplete type ` servent' And Mingw: * Missing header file: HsNet.h This problem can usually be solved by installing the system package that provides this library (you may need the "-dev" version). If the library is already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where it is. cabal.exe: Error: some packages failed to install: network-2.2.1.2 failed during the configure step. The exception was: exit: ExitFailure 1 And Windows command line: Resolving dependencies... Configuring network-2.2.1.2... cabal: Error: some packages failed to install: network-2.2.1.2 failed during the configure step. The exception was: sh: runProcess: does not exist (No such file or directory) Was removal of these packages on the stable branch was an oversight? Could network at the very least be reinstated soon? I'd love to report back whether the GHC 6.10.4 fixes work or not in practice. Thanks Neil _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users(a)haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

2 1

runghc failing sometimes on Linux/ppc?
by Jens Petersen 23 May '09

23 May '09

I am seeing some strange failures of runghc on Linux/ppc (Fedora 11 specifically) with ghc-6.10.1 and ghc-6.10.2. For example "cabal install HTTP" works fine but "runghc Setup" failing to run. A workaround (other than using cabal-install) seems to be to compile Setup and then use the output of that to build the package. More strangely this only happens sometimes in the buildsystem, which makes me wonder if it is a fedora issue: most packages built ok in the fedora buildsystem except HTTP and haddock so far. http://koji.fedoraproject.org/koji/getfile?taskID=1319083&name=build.log http://koji.fedoraproject.org/koji/getfile?taskID=1320158&name=build.log On the other hand in a ppc box I tested on runghc seemed to fail consistently. ghci also segfaulted there. Anyway I thought I would ask here if anyone else had experienced something like this. Jens

2 5

Extensible Exceptions and IO
by Alexander Dunlap 23 May '09

23 May '09

In the extensible exceptions paper[1], which I believe is the guide behind the current Control.Exception in GHC 6.10, a SomeIOException type is discussed so that it would be possible to use the nice interface for IOExceptions. Is this implemented anywhere? In the GHC libraries, all I see is the old interface just plugged into a simple wrapper, so you have to use guard . isDoesNotExistError (for example) with catchJust to catch a certain type of exception. If not, are there any plans to implement it? Alex

2 2

Re: [Haskell-cafe] A problem with par and modules boundaries...
by Duncan Coutts 23 May '09

23 May '09

On Fri, 2009-05-22 at 05:30 -0700, Don Stewart wrote: > Answer recorded at: > > http://haskell.org/haskellwiki/Performance/Parallel I have to complain, this answer doesn't explain anything. This isn't like straight-line performance, there's no reason as far as I can see that inlining should change the operational behaviour of parallel evaluation, unless there's some mistake in the original such as accidentally relying on an unspecified evaluation order. Now, I tried the example using two versions of ghc and I get different behaviour from what other people are seeing. With the original code, (ie parallelize function in the same module) with ghc-6.10.1 I get no speedup at all from -N2 and with 6.11 I get a very good speedup (though single threaded performance is slightly lower in 6.11) Original code ghc-6.10.1, -N1 -N2 real 0m9.435s 0m9.328s user 0m9.369s 0m9.249s ghc-6.11, -N1 -N2 real 0m10.262s 0m6.117s user 0m10.161s 0m11.093s With the parallelize function moved into another module I get no change whatsoever. Indeed even when I force it *not* to be inlined with {-# NOINLINE parallelize #-} then I still get no change in behaviour (as indeed I expected). So I view this advice to force inlining with great suspicion (at worst it encourages people not to think and to look at it as magic). That said, why it does not get any speedup with ghc-6.10 is also a mystery to me (there's very little GC going on). Don: can we change the advice on the wiki please? It currently makes it look like a known and understood issue. If anything we should suggest using a later ghc version. Duncan

2 1

ANNOUNCE: GHC version 6.10.3
by Ian Lynagh 23 May '09

23 May '09

============================================================== The (Interactive) Glasgow Haskell Compiler -- version 6.10.3 ============================================================== The GHC Team is pleased to announce a new patchlevel release of GHC. This release contains a handful of bugfixes relative to 6.10.2 and better line editing support in GHCi, so we recommend upgrading. Release notes are here: http://haskell.org/ghc/docs/6.10.3/html/users_guide/release-6-10-3.html How to get it ~~~~~~~~~~~~~ The easy way is to go to the web page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language; the current language version is Haskell 98, agreed in December 1998 and revised December 2002. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ GHC developers' home page http://hackage.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, is here: http://hackage.haskell.org/trac/ghc/wiki/Contributors Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://hackage.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: http://hackage.haskell.org/trac/ghc/ Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Some GHC developers hang out on #haskell on IRC, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug

4 6

Re: [Haskell-cafe] A problem with par and modules boundaries...
by Duncan Coutts 23 May '09

23 May '09

On Fri, 2009-05-22 at 16:34 +0200, Daniel Fischer wrote: > > That's great, thank you. I am still baffled, though. I'm baffled too! I don't see the same behaviour at all (see the other email). > > Must every exported function that uses `par' be INLINEd? Does every > > exported caller of such a function need the same treatment? It really should not be necessary. > > Is `par' really a macro, rather than a function? It's a function. > As far as I understand, par doesn't guarantee that both arguments are > evaluated in parallel, it's just a suggestion to the compiler, and if > whatever heuristics the compiler uses say it may be favourable to do > it in parallel, it will produce code to calculate it in parallel > (given appropriate compile- and run-time flags), otherwise it produces > purely sequential code. > > With parallelize in a separate module, when compiling that, the > compiler has no way to see whether parallelizing the computation may > be beneficial, so doesn't produce (potentially) parallel code. At the > use site, in the other module, it doesn't see the 'par', so has no > reason to even consider producing parallel code. I don't think this is right. As I understand it, par always creates a spark. It has nothing to do with heuristics. Whether the spark actually gets evaluated in parallel depends on the runtime system and whether the spark "fizzles" before it gets a chance to run. Of course when using the single threaded rts then the sparks are never evaluated in parallel. With the threaded rts and given enough CPUs, the rts will try to schedule the sparks onto idle CPUs. This business of getting sparks running on other CPUs has improved significantly since ghc-6.10. The current development version uses a better concurrent queue data structure to manage the spark pool. That's probably the underlying reason for why the example works well in ghc-6.11 but works badly in 6.10. I'm afraid I'm not sure of what exactly is going wrong that means it doesn't work well in 6.10. Generally I'd expect the effect of par to be pretty insensitive to inlining. I'm cc'ing the ghc users list so perhaps we'll get some expert commentary. Duncan

2 1

Mac OS X 64bit unregisterised port
by Ian Lynagh 23 May '09

23 May '09

Hi all, There is an unregisterised bindist for Mac OS X 64bit here: http://www.haskell.org/ghc/dist/current/ports/ghc-6.11.20090521-x86_64-appl… Thanks Ian

2 2

ANNOUNCE: GHC porting works again
by Ian Lynagh 22 May '09

22 May '09

Hi all, The instructions for porting GHC to a new architecture now work again with the HEAD: http://hackage.haskell.org/trac/ghc/wiki/Building/Porting If you get stuck when trying to do a port, then please feel free to ask us on cvs-ghc(a)haskell.org or in #ghc on freenode. Thanks Ian

1 0