- Glasgow-haskell-users

keyword in pragma
by Serge D. Mechveliani 07 Feb '10

07 Feb '10

In my last letter I wrote about the prossibility for the GHC developers to require a keyword in any pragma, "for future". I thought that pragma is a matter of the GHC language extension. But if it is of the Haskell standard, then, again I am sorry! Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

Re: forgetting SCC
by Serge D. Mechveliani 07 Feb '10

07 Feb '10

I am sorry, indeed, ghc-6.12.1 warns of Unrecognised pragma on {-# "foo" #-}. I have just missed this warning. The next question is: why it is a warning and not an error break? ----------------- Serge Mechveliani mechvel(a)botik.ru On Sun, Feb 07, 2010 at 10:56:53AM +0000, Ian Lynagh wrote: > On Sun, Feb 07, 2010 at 11:39:31AM +0300, Serge D. Mechveliani wrote: > > On Sat, Feb 06, 2010 at 08:24:07PM +0000, Ian Lynagh wrote: > > > On Sun, Jan 31, 2010 at 10:09:42PM +0300, Serge D. Mechveliani wrote: > > > > I have a suggestion: > > > > is it better for GHC to report an error on the source of kind > > > > {-# "foo" #-} > > > > (entered by a typo instead of {-# SCC "foo" #-}) ? > > > > Currently, GHC makes the program under (-prof) in which, the "foo" center > > > > occurs skipped. This misleads the user: > > > > "foo is not in the profiling head, so it takes zero cost". > > > > > > 6.12.1 will warn: > > > > > > q.hs:3:0: Unrecognised pragma > > > > > > by default. > > > > May be, you mean the version next to 6.12.1 ? > > Because this my report is exactly on 6.12.1. > > No, in 6.12.1: > > $ cat Q.hs > > module Q where > > {-# "foo" #-} > > $ ghci Q.hs > GHCi, version 6.12.1: http://www.haskell.org/ghc/ :? for help > Loading package ghc-prim ... linking ... done. > Loading package integer-gmp ... linking ... done. > Loading package base ... linking ... done. > Loading package ffi-1.0 ... linking ... done. > [1 of 1] Compiling Q ( Q.hs, interpreted ) > > Q.hs:4:0: Unrecognised pragma > Ok, modules loaded: Q. > *Q> > > > Thanks > Ian > >

2 4

forgetting SCC
by Serge D. Mechveliani 06 Feb '10

06 Feb '10

I have a suggestion: is it better for GHC to report an error on the source of kind {-# "foo" #-} (entered by a typo instead of {-# SCC "foo" #-}) ? Currently, GHC makes the program under (-prof) in which, the "foo" center occurs skipped. This misleads the user: "foo is not in the profiling head, so it takes zero cost". Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

2 1

Quasi quoting
by Simon Peyton-Jones 06 Feb '10

06 Feb '10

Dear GHC users This email is to announce two proposed changes to GHC's quasi-quotation mechanism. For all I know, no one is using quasi-quotation (although it's a very cool feature, thanks to Geoff Mainland), but I didn't think I should take it for granted! The current spec is here: http://haskell.org/haskellwiki/Quasiquotation http://www.haskell.org/ghc/docs/latest/html/users_guide/template-haskell.ht… A quasi-quote can appear as a (a) expression (b) pattern, and looks like this [$pads| ...blah... |] where 'pads' (of course any name will do) is a record of functions data QuasiQuoter = QuasiQuoter { quoteExp :: String -> Q Exp quotePat :: String -> Q Pat } The idea is that GHC evaluates (pads "...blah..."), and splices in the resulting Exp (or Pat) just as if that's what the user wrote in the first place. Kathleen Fisher has started to use this for her PADS system, and came up with two suggestions. 1. Allow quasi-quotes at the (top-level) declaration level, just like TH splices. So you could say, at top level [$pads| ...blah... |] and have it expand to a bunch of top level Haskell declarations. This seems like an unconditionally good idea. To support it we'd need to add a field to QuasiQuoter: data QuasiQuoter = QuasiQuoter { quoteExp :: String -> Q Exp quotePat :: String -> Q Pat quoteDec :: String -> Q [Dec] } but I don't think anyone will lose sleep over that. 2. Make the notation less noisy for the "customer". In particular, that '$' is scary, and redundant to boot. She would like to write [pads| ...blah... |] I can see the motivation here, but there are two reasons for caution. (i) The Template Haskell quote forms [t| ... |] and [d| ... |] behave rather differently. (ii) If "[pads|" is a lexeme, then some list comprehensions become illegal, such as [x|x<-xs,y<-ys]. But note that because of Template Haskell quotations, a comprehension [t|t<-ts] is already broken, and similarly with 'd', 'e'. So the proposed change will make things *more* uniform, by grabbing every "[blah|" as lexeme. For me (i) is the main issue. The differences are significant. - A TH quote can appear only where an *expression* is expected But a quasiquote can be an expression or pattern or (assuming (1)) declaration - A TH quote has type (Q Typ) or (Q [Dec]) or (Q Exp) But a quasiquote is run immediately and spliced in place of the quote - A TH splice is run during type checking But a quasiquote is run during renaming Even given all that, I'm strongly inclined to follow Kathleen's suggestion: - The differences are there all right, but in some ways the programmer thinks the same way: [lang| blah |] switches to language 'lang'. - Many users will never encounter the issue; they'll just say [pads| blah |] to wake up the PADS magic, and be oblivious to Template Haskell quotes An alternative would be to have some other cue. Ones I've considered - $[pads| ...|], but allowing the $ to be omitted on top-level declarations, top level, just as it now can for TH splices. - [pads:| ... |], with the colon distinguishing quasi-quoting from TH. My gut feel is to go with [|pads| ... |]. Of course this'd be a change from the current syntax, but I think there are few enough users that they'll switch easily enough. Any comments on any of this? Simon

14 27

Template Haskell pattern quotations
by Brad Larsen 04 Feb '10

04 Feb '10

I'll put my question at the very front of this message, and then give the context. My question: Are Template Haskell pattern quotations (i.e., [p| ... |]) not implemented in GHC because they are rather tricky to implement, or because there has not been demand for them? And now, the context. I am working on an embedded DSL/compiler in Haskell, and I want to make use of the recently-much-discussed quasiquoting mechanism to ease reading & writing various transformations. I read through the quasiquoting paper [1] again and played around with some simple examples. In the paper, Data.Generics is used so that the same parser can be used for quasiquoting both expressions and patterns. This requires adding constructors to the ASTs being quasiquoted for antiquotations to be possible. In my application, I don't anticipate using Data.Generics for parser reuse, for a few reasons: * I haven't read the SYB papers, and don't understand how Data.Generics or Data.Data work. * My ASTs in some cases involve GADTs with several phantom type parameters (is that the right terminology?), and DeriveDataTypeable does not work with them. * I don't want to add the extra constructors necessary to support antiquotation with the Data.Generics approach. So, I'm stuck writing separate ExpQ / PatQ parsers. (Actually, I can write the parser once, if it takes a dictionary of semantic actions as a parameter, in which case I only need to write the dictionary of ExpQ actions and the dictionary of PatQ actions.) When writing the ExpQ parser, I can use Template Haskell expression quotations, [| ... |]. When writing the PatQ parser, I have to resort to using the various pattern construction combinators, which is unfortunate! I'd like to be able to use pattern quotations instead. So, my question once again: How hard would it be to implement the pattern quotations from the Template Haskell paper in GHC? Sincerely, Brad References: [1] Geoffrey B. Mainland. Why It's Nice to be Quoted: Quasiquoting for Haskell. <http://www.eecs.harvard.edu/~mainland/ghc-quasiquoting/mainland07quasiquoti…>

4 5

profiling,-O in 6.12.1
by Serge D. Mechveliani 04 Feb '10

04 Feb '10

Dear GHC team, It looks like ghc-6.12.1 reports erroneous time profiling -- when the Main module of the project is made under -O. This is for ghc-6.12.1 made from source for Debian Linux and i386-like. Main.main calls for Complete.complete, `complete' calls for eLoop inside its source. eLoop must take almost all the time. My whole user library is made under -O -prof, and --enable-library-profiling. Main is compiled by ghc $dmCpOpt -prof --make Main and run by ./Main +RTS -M400m -pT -RTS For this key, the profiling report Main.prof looks natural and shows eLoop -- 97%. But for ghc $dmCpOpt -O -prof --make Make, it shows a different thing: zero for eLoop and 99% for `main'. How could this additional -O mislead the compiler? Also, as I recall, -O is still by default -- ? Could you explain, please? Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

3 4

question about hsc2hs
by Jose A. Ortega Ruiz 04 Feb '10

04 Feb '10

Hi. I'm copying below a question i sent to another list about hsc2hs (and for which i got no response), in the hopes that it will be not be OT here. My apologies if it is! I'm trying to write a simple C binding for statfs(2). Simplifying, writing an hsc file that contains the following snippet: #include <sys/vfs.h> data CStatfs foreign import ccall unsafe "sys/vfs.h statfs" c_statfs :: CString -> Ptr CStatfs -> IO CInt getFileSystemStats :: String -> IO CLong getFileSystemStats path = allocaBytes (#size struct statfs) $ \vfs -> useAsCString (pack path) $ \cpath -> do res <- c_statfs cpath vfs case res of -1 -> return 0 _ -> do bsize <- (#peek struct statfs, f_bsize) vfs bcount <- (#peek struct statfs, f_blocks) vfs bfree <- (#peek struct statfs, f_bfree) vfs bavail <- (#peek struct statfs, f_bavail) vfs -- Just for demonstration: the original code creates a data structure return $ bsize + bcount + bavail + bfree gives rise, when using hsc2hs, to this translation: getFileSystemStats path = allocaBytes ((84)) $ \vfs -> useAsCString (pack path) $ \cpath -> do res <- c_statfs cpath vfs case res of -1 -> return 0 _ -> do bsize <- ((\hsc_ptr -> peekByteOff hsc_ptr 4)) vfs bcount <- ((\hsc_ptr -> peekByteOff hsc_ptr 8)) vfs bfree <- ((\hsc_ptr -> peekByteOff hsc_ptr 16)) vfs bavail <- ((\hsc_ptr -> peekByteOff hsc_ptr 24)) vfs return $ bsize + bcount + bavail + bfree (where i have deleted LINE directives). The problem is that the size and some of the offsets of the C struct statfs computed by hsc2c are wrong: i'm in a 32bit linux system, and i've checked, using a C program, that sizeof(struct statfs) is 64 (hsc2 is giving 84 -- although perhaps Haskell needs additional space for housekeeping?), and that the offsets of f_bfree and f_bavail are, respectively, 12 and 16 (not 16 and 24). Also, i know that 12 and 16 are the right values because putting them by hand gives me the correct statfs values. (This is ghc 6.10.4 on a debian/sid system) What am i doing wrong? TIA! jao -- It is hard enough to remember my opinions, without also remembering my reasons for them. -Friedrich Wilhelm Nietzsche, philosopher (1844-1900)

2 3

Question regarding combinator call convention
by Tyson Whitehead 01 Feb '10

01 Feb '10

I was looking through the code for 6.12.1 and am a bit confused about 11.1.3 in the runtime system documentation docs/rts/rts.tex. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.79.641&rep=rep1&ty… It says the arguments passing convention to a known combinator differs from that of the others in that it starts the arguments with R1 instead of R2 (R1 points to the associated memory data structure for non-combinators). The thing I'm confused with is I would expect this would require treating combinators special, and yet I don't see an combinator specific stuff (in either ClosureTypes.h or the generated AutoApply.cmm) to treat them special. Ive also looking at functions like plusInt and a few of my own, but, apart from internal functions like stg_app_*, I'm not finding any code using the the combinator passing convention. Am I missing something? Thanks! -Tyson

2 2

building 6.12.1 with itself
by Nicolas Martyanoff 01 Feb '10

01 Feb '10

Hi, By reading Matthias Kilian's scripts (thank you !), I successfully builded GHC 6.12.1. GHC 6.10.4 didn't build: g Lexer.x gmake[2]: g: Command not found gmake[2]: [Lexer.hs] Error 127 (ignored) RTS -K2m -RTS -agc --strict Parser.y gmake[2]: RTS: Command not found gmake[2]: *** [Parser.hs] Error 127 Failed making boot in genprimopcode: 1 gmake[1]: *** [boot] Error 1 gmake: *** [stage1] Error 1 But GHC 6.8.3 did. I then built GHC 6.12.1. The only problem was that the build process doesn't find the iconv lib when it's installed in /usr/local, so the lib/include paths have to be specified when running ./configure. I then installed Cabal 1.9 from darcs, and cabal-install, still from darcs. I used cabal to install hscolour, xmonad and xmonad-contrib, it worked perfectly. I thought it might be good to build GHC 6.12.1 with itself just to be sure it's working fine before make a dist, but I now get the following error: "/usr/local/bin/ghc" -H32m -O -package-conf libraries/bootstrapping.conf -package-name ghc-6.12.1 -hide-all-packages -i -icompiler/nativeGen -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/cprAnalysis -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/main -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.9.0 -package array-0.3.0.0 -package base-4.2.0.0 -package bin-package-db-0.0.0.0 -package bytestring-0.9.1.5 -package containers-0.3.0.0 -package directory-1.0.1.0 -package filepath-1.1.0.3 -package hpc-0.5.0.4 -package old-time-1.0.0.3 -package process-1.0.1.2 -package unix-2.4.0.0 -DSTAGE=1 -Wall -fno-warn-name-shadowing -fno-warn-orphans -XCPP -XMagicHash -XUnboxedTuples -XPatternGuards -XForeignFunctionInterface -XEmptyDataDecls -XTypeSynonymInstances -XMultiParamTypeClasses -XFlexibleInstances -XRank2Types -XScopedTypeVariables -XDeriveDataTypeable -XRelaxedPolyRec -odir compiler/stage1/build -hidir compiler/stage1/build -stubdir compiler/stage1/build -hisuf hi -osuf o -hcsuf hc -c compiler/main/Packages.lhs -o compiler/stage1/build/Packages.o compiler/main/Packages.lhs:233:63: Couldn't match expected type `InstalledPackageInfo_ String' against inferred type `Cabal-1.8.0.2:Distribution.InstalledPackageInfo.InstalledPackageInfo_ m' Expected type: [InstalledPackageInfo_ String] Inferred type: [Cabal-1.8.0.2:Distribution.InstalledPackageInfo.InstalledPackageInfo_ m] In the second argument of `map', namely `conf' In the first argument of `return', namely `(map installedPackageInfoToPackageConfig conf)' gmake[1]: *** [compiler/stage1/build/Packages.o] Error 1 gmake: *** [all] Error 2 I tried to "ghc-pkg mask" Cabal-1.8.0.2, then Cabal-1.9.0, didn't change anything. Does someone know what's going on here, and what can be done to fix it ? Regards, -- Nicolas Martyanoff http://codemore.org khaelin(a)gmail.com

2 1

Language extensions - backwards compatibility
by Iain Alexander 30 Jan '10

30 Jan '10

I'm looking for a way of specifying language extensions in a way which will work in all versions of GHC from 6.4 onwards. GHC 6.4 does not support the LANGUAGE pragma. Specifying language options in the OPTIONS_GHC pragma starts to produce deprecation warnings in 6.10, and will presumably eventually fail altogether. Any sort of preprocessing at the beginning of a file appears to insert enough noise to inhibit recognition of file-header pragmas. (Cpphs doesn't appear to help here.) Attempting preprocessing inside a leading OPTIONS_GHC pragma fails because it apparently attempts to interpret the pragma *before* invoking the preprocessor. The only remaining option I can see is to have a completely separate version of the file for GHC 6.4. Have I missed anything? -- Iain Alexander ia(a)stryx.demon.co.uk

5 8