- Glasgow-haskell-users

Proposal: Deprecate ExistentialQuantification
by Niklas Broberg 24 Jul '09

24 Jul '09

Hi all, Following the discussion on the use of 'forall' and extensions that use it [1], I would hereby like to propose that the ExistentialQuantification extension is deprecated. My rationale is as follows. With the introduction of GADTs, we now have two ways to write datatype declarations, the old simple way and the GADTs way. The GADTs way fits better syntactically with Haskell's other syntactic constructs, in all ways. The general style is (somewhat simplified) "keyword type 'where' decls", where keyword can in Haskell 98 be class or instance, but with GADTs also data. The old simple way of defining data types is the odd one out. It certainly has its uses though, in particular when defining some simple (but possibly large) enum-like datatype (like cabal's Extension type incidentally), then it obviously becomes tedious to have to restate the trivial type signature for each constructor. Using GADTs style syntax it is possible to allow constructors with existentially quantified arguments with *no additional syntax needed*. It follows nicely from the standard syntax for type signature declarations (assuming explicit foralls), e.g. the following "normal" datatype declaration data Foo = forall a . Show a => Foo a which uses ExistentialQuantification syntax, could be written as data Foo where Foo :: forall a . Show a => a -> Foo which is syntactically just a normal type signature. The upside of deprecating ExistentialQuantification is thus that we keep the syntax cleaner, and we keep the old style of datatype declarations simple (as it should be, IMO). Anything fancier can use the GADTs syntax, which anyone that uses something fancier should be acquainted with anyway. The downside is that we lose one level of granularity in the type system. GADTs enables a lot more semantic possibilities for constructors than ExistentialQuantification does, and baking the latter into the former means we have no way of specifying that we *only* want to use the capabilities of ExistentialQuantification. My own take on that is that what we have now is a wart that should be removed, and that if we think that the latter is a problem then the way to go would be to split the monolithic GADTs extension into several semantic levels. There is of course also the downside that we break existing code, but that's a standard problem with improvement through deprecation which I will pay no mind. Discussion period: 2 weeks Cheers, /Niklas [1] http://www.haskell.org/pipermail/glasgow-haskell-users/2009-June/017432.html

12 23

Proposal: ExplicitForall
by Niklas Broberg 23 Jul '09

23 Jul '09

Hi all, (I'm writing this to several lists since it involves GHC (implementation of extensions), cabal (registration of extensions) and some future Haskell standard (formalisation of extensions).) In my quest to implement all known syntactic extensions to Haskell in my haskell-src-exts package, I've become painfully aware of the sometimes ad-hoc nature that these extensions have been added to GHC. This should not be taken as criticism per se, GHC is awesome and I'm sure a lot of thought and research has gone into all of these extensions. I think the problem (from my point of view) is rather that most of the extensions are only really "interesting" on a type system level, whereas the syntactic level is rather trivial, and thus the latter has (rightly) gotten far less formal attention. I hope my putting the light on these issues will be a help and a kickoff towards improving the state of formalisation of the known and registered (with Cabal) extensions. One of the most blatant and (to me) problematic such issues is the matter of using 'forall'. GHC has a number of extensions relating to the use of forall-quantified types in various interesting ways. With none of these extensions on, forall is not considered a keyword, so the syntax with explicit forall quantification cannot be used at all ('forall' is considered a varid). However, with *any* extension on that relates to forall-quantified types, forall is a keyword, and can syntactically be used in types *anywhere*. This doesn't mean all such types will pass the type checker, most of them won't in fact, but syntactically there is really no (or at least very little) difference. Conceptually, all of these extensions (specifically PolymorphicComponents, Rank2Types, RankNTypes, LiberalTypeSynonyms and ScopedTypeVariables (and strangely also ExistentialQuantification)) thus have one thing in common. They all enable syntactically forall-quantified types. They allow different uses of these types as far as the type system is concerned, but syntactically there is no difference between type and type (in fact there cannot be, as I discussed in a recent blog post [1]). Funnily enough there are also some uses of forall-quantified types that are common to all of these extensions - using a forall just to make polymorphism explicit in a type doesn't change anything as far as the type system is concerned, so e.g. the types '(Eq a) => a -> Bool' and 'forall a . (Eq a) => a -> Bool' are equivalent. The latter type can be given to a function when any of the listed six extensions are given, even if most of them have nothing to do with this at all! So, what I'm getting at is an idea that Isaac Dupree gave as a comment to my blog post. He said: "I wish there was a plain old ExplicitForall extension that enabled the keyword in types (without extending the type checker -- only like (id :: forall a. a -> a) would be allowed)". I think this is a really great idea. I find it conceptually appealing, since I think it covers exactly that blind spot that is the seemingly unintended intersection between all these extensions. And it also makes the separation of concern between the syntactic level and the type system more clear. Any formalisation of any of the type system extensions would not need to bother with syntactic details, but can simply be said to imply ExplicitForall. I would thus like to propose the following formalisation of the ExplicitForall extension: ========================================= ExplicitForall enables the use of the keyword 'forall' to make a type explicitly polymorphic. Syntactically, it would mean the following change to Haskell 98: * 'forall' becomes a reserved word. * '.' (dot) becomes a special (not reserved) operator. * The following syntactic rule changes: type -> 'forall' tyvars '.' type | context '=>' type | ftype ftype -> btype '->' type | btype gendecl -> vars '::' type It does not allow the use of explicitly polymorphic types in any way not already allowed by Haskell 98 for implicitly polymorphic types. ========================================= One thing to note is that I haven't touched the matter of ExistentialQuantification in the above. Syntactically this is a different beast entirely, and could well be handled separately, though it's really an artifact of the way we (by default) write our data type declarations. Using GADT-style declarations, existential quantification goes nicely along with the others by following the same syntactic rules for types, even though from a type system it is of course still quite different from the rest. But with the ordinary Haskell 98 declaration style, we could define the syntactic part of the ExistentialQuantification extension as the following: ========================================= ExistentialQuantification allows data constructors to take existentially quantified arguments. Syntactically, it means the following changes to Haskell98: * 'forall' becomes a reserved word. * '.' (dot) becomes a special (not reserved) operator. * The following syntactic rule changes: constrs -> econstr_1 '|' ... '|' econstr_n econstr -> ['forall' tyvars '.' [context '=>']] constr ========================================= My hope is that you'll all agree with me on the need and rationale for the ExplicitForall extension, and that my proposal for formalisation is good enough for adoption. I feel much less strongly about ExistentialQuantification, and would love to hear some more input on that matter, but I do think it needs to be addressed one way or the other. Thoughts? Cheers, /Niklas [1] http://nibrofun.blogspot.com/2009/06/whats-in-forall.html

3 4

Fwd: Generating valid Haskell code using the GHC API pretty printer
by Thomas Schilling 23 Jul '09

23 Jul '09

Forgot to include the list. ---------- Forwarded message ---------- From: Thomas Schilling <nominolo(a)googlemail.com> Date: 2009/7/22 Subject: Re: Generating valid Haskell code using the GHC API pretty printer To: Jan Schaumlöffel <jsch(a)informatik.uni-kiel.de> The pretty printer never prints { .. } for a do expression. You can control which things are printed unqualified by setting the "PrintUnqualified" part properly. The most straightforward way is to use GHC.mkPrintUnqualifiedForModule which only prints things qualified that are not imported in the given module. See 'withPprStyle' and 'mkUserStyle' in Outputable. That said, if you're trying to do source-to-source transformations you probably want to keep the original layout as much as possible. GHC's pretty-printer isn't designed for that. GHC's syntax tree has very accurate source locations, so you could start from there and build your own pretty printer. 2009/7/22 Jan Schaumlöffel <jsch(a)informatik.uni-kiel.de>: > Hello everyone, > > we are trying to use the GHC API for a source-to-source transformation > on Haskell programs. The result of parsing and typechecking a module > enables us to apply the transformation, but writing the transformed > module back using the pretty printer (Outputable) generates invalid > Haskell code. > > For one thing, since even the names defined in the current module are > fully qualified, the resulting code is not valid anymore. > > This can be worked around, but there is another issue: Simply reading > the following program and then writing it out using the pretty printer > renders the resulting code invalid. > >> module Main where >> main = do >> if True then putStrLn "longlonglonglonglonglongline" >> else return () >> longlonglonglonglonglonglonglonglonglonglonglongname $ "test" >> longlonglonglonglonglonglonglonglonglonglonglongname = putStrLn > > The result looks like this: > >> Main.main = do if GHC.Bool.True then >> System.IO.putStrLn "longlonglonglonglonglongline" >> else >> GHC.Base.return () >> Main.longlonglonglonglonglonglonglonglonglonglonglongname >> GHC.Base.$ >> "test" >> Main.longlonglonglonglonglonglonglonglonglonglonglongname = System.IO.putStrLn > > There are two different problems in this output: > > 1) the indentation of "if ... then ... else" violates the "do"-block > layout rule > 2) the indentation of the long function call is invalid > > It looks like those problems could be avoided if the pretty printer > could be configured to consistently use "do { ... ; ... }" notation, > but we have been unable to figure out how. Is there a canonical way > to use the GHC API to pretty print to valid Haskell code? > > Kind regards, > Jan > > Appended is our current code to execute the transformation above (the > module to be read is expected in a file "dummy.hs" for simplicity). > Please excuse if this might not be a minimal example. > > module Main where > > import GHC > import GHC.Paths > import Outputable > > main = do > x <- runGhc (Just libdir) $ do > dflags <- getSessionDynFlags > setSessionDynFlags (dflags { hscTarget = HscNothing, > ghcLink = NoLink }) > > target <- guessTarget "dummy.hs" Nothing > setTargets [target] > load LoadAllTargets > > graph <- getModuleGraph > let unparsedmod = head graph > > parsedmod <- parseModule unparsedmod > typecheckedmod <- typecheckModule parsedmod > let Just renamedsource = renamedSource typecheckedmod > (group,_,_,_,_) = renamedsource > moduledings = (ms_mod unparsedmod) > > return (showSDoc (ppr group)) > putStr $ x ++ "\n" > > -- > If you're happy and you know it, syntax error! > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > -- Push the envelope. Watch it bend. -- Push the envelope. Watch it bend.

4 3

Unpacking multi-type constructors
by Louis Wasserman 22 Jul '09

22 Jul '09

I think this is a feasible idea. Whether this is in fact a good idea is an entirely separate question, however, and I want feedback. Currently, I believe that an UNPACK pragma used on a multi-constructor type has no effect. For example, data Node = Node Int {-# UNPACK #-} !(Maybe Node) {-# UNPACK #-} !(Maybe Node) is the same as data Node = Node Int !(Maybe Node) !(Maybe Node) What I'd like is for this to translate into four constructors, one for each combination of constructors for the UNPACK'd fields: data Node = Node0 Int -- Nothing, Nothing | Node1 Int Node -- Just, Nothing | Node2 Int Node -- Nothing, Just | Node3 Int Node Node -- Just, Just The primary counterargument I can think of is that this can result in a single-constructor type being turned into a multi-constructor type, which runs the risk of interfering with GHC's sexcellent handling of single-constructor types. The countercounterargument is, of course, that the {-# UNPACK #-} pragma already behaves differently depending on the single-constructorness of the underlying type, and that the obligation is already on the programmer to check such things. For reference, could somebody point me to the place in GHC that currently takes care of {-# UNPACK #-} pragmas, so I could -- for instance -- figure out whether or not there's another reason that this idea isn't in place already? Louis Wasserman wasserman.louis(a)gmail.com

3 3

[relapse.dev@gmx.com: [Haskell-cafe] System.Mem.performGC leaks?]
by Don Stewart 22 Jul '09

22 Jul '09

Interesting. ----- Forwarded message from Neal Alexander <relapse.dev(a)gmx.com> ----- Date: Tue, 21 Jul 2009 18:48:38 -0700 From: Neal Alexander <relapse.dev(a)gmx.com> To: haskell-cafe(a)haskell.org Subject: [Haskell-cafe] System.Mem.performGC leaks? main = forever performGC The OS reported memory usage skyrockets. If i enable +RTS -S the GC statistics show the heap "live bytes" being constant. Is it accumulating statistics even when profiling is disabled (and can you turn that off), or is there something going on with the FFI call to performGC. Compiled with "ghc -O2 -fvia-C -optc-O2 -funbox-strict-fields -threaded" btw. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ----- End forwarded message -----

1 0

"Could not deduce (MArray (STUArray s) Int (ST s)) from context ()" when applying runST
by Christian Klauser 21 Jul '09

21 Jul '09

Hi, I'm in the process of learning haskell and came across this problem: Using `Glasgow Haskell Compiler, Version 6.10.4, for Haskell 98, stage 2 booted by GHC version 6.10.1` Common beginning of the file ============================ {-# LANGUAGE FlexibleContexts #-} module UPSO where import Control.Monad(forM,forM_) import Control.Monad.ST.Lazy (ST,runST) import Data.Array.MArray (MArray, Ix, getBounds, newArray, readArray, writeArray) import Data.Array.ST (STArray,STUArray) minmax xs@(x:_) = foldr (\x (l,u) -> (min x l,max x u)) (x,x) xs modify a i f = do x <- readArray a i writeArray a i (f x) increment a i = modify a i (+1) decrement a i = modify a i (\x -> x - 1) uniquePermutationsM t 0 = return $! [[]] uniquePermutationsM t pos = do (l,u) <- getBounds t perms <- forM [l..u] (\d -> do count <- readArray t d -- t[d] if count == 0 then return $! [] else do decrement t d pss <- uniquePermutationsM t (pos-1) increment t d return $! (map (d:) pss) ) return $! (concat perms) Using STArray (works) ===================== mkArray :: (Int,Int) -> (ST s) (STArray s Int Int) mkArray bounds = newArray bounds 0 uniquePermutationsST :: [Int] -> ST s [[Int]] uniquePermutationsST xs = do let bounds@(l,u) = (minmax xs) t <- mkArray bounds forM_ xs (increment t) pos <- sum `fmap` mapM (readArray t) [l..u] uniquePermutationsM t pos uniquePermutations xs = runST (uniquePermutationsST xs) Using STUArray (doesn't work) ============================= But when I try to switch to unboxed arrays, I get an error message. mkArray :: (Int,Int) -> (ST s) (STUArray s Int Int) mkArray bounds = newArray bounds 0 uniquePermutationsST :: [Int] -> ST s [[Int]] uniquePermutationsST xs = do let bounds@(l,u) = (minmax xs) t <- mkArray bounds forM_ xs (increment t) pos <- sum `fmap` mapM (readArray t) [l..u] uniquePermutationsM t pos uniquePermutations xs = runST (uniquePermutationsST xs) Error messages ============== Could not deduce (MArray (STUArray s) Int (ST s)) from the context () arising from a use of 'newArray' at UPSO.hs:35:17-33 Possible fix: add (MArray (STUArray s) Int (ST s)) to the context of the type signature for 'mkArray' or add an instance declaration for (MArray (STUArray s) Int (ST s)) In the expression: newArray bounds 0 In the definition of 'mkArray': mkArray bounds = newArray bounds 0 and also: Could not deduce (MArray (STUArray s) Int (ST s)) from the context () arising from a use of 'increment' at UPSO.hs:41:14-24 After almost two hours of fiddling with the type annotations I hope someone can point me in the right direction. What on earth is going wrong? Thank you for your time.

3 4

HPC gives spurious results if sources are compiled with -cpp
by Dominic Steinitz 18 Jul '09

18 Jul '09

Trac doesn't seem to work for us so I'm sending this bug report by email. ghc --version The Glorious Glasgow Haskell Compilation System, version 6.10.1 ghc.exe -fhpc -cpp --make CommonHPC.hs -o CommonHPC commonHPC hpc markup CommonHPC --fun-entry-count This gives no entry counts for fact in Common.hs. With more complex modules, you get spurious red, yellow and green over expressions. Dominic. CommonHPC.hs: module Main (main) where import Common main = do test test test = do putStrLn $ show $ fact 4 putStrLn $ show $ fact 5 Common.hs: module Common ( fact ) where fact 0 = 1 fact n = n * fact (n-1)

4 7

Re: CLDouble serialization bug in 6.10.1
by Jeff Heard 17 Jul '09

17 Jul '09

There is a package for serializing doubles on Hackage, Data.Bunary.IEEE754. See: http://hackage.haskell.org/package/data-binary-ieee754 -- Jeff On Fri, Jul 17, 2009 at 1:57 PM, Jeff Heard<jefferson.r.heard(a)gmail.com> wrote: > Bulat, > > There is a package for serializing doubles on Hackage, > Data.Bunary.IEEE754. See: > http://hackage.haskell.org/package/data-binary-ieee754 > > -- Jeff > > On Fri, Jul 17, 2009 at 1:26 PM, Ian Lynagh<igloo(a)earth.li> wrote: >> >> Hi Bulat, >> >> On Sat, Jul 11, 2009 at 09:32:43PM +0400, Bulat Ziganshin wrote: >>> >>> > foreign import ccall unsafe "" >>> > client :: Ptr CLDouble -> IO () >> >> I'm afraid GHC has never supported CLDouble properly. It's been removed >> from the HEAD: >> http://hackage.haskell.org/trac/ghc/ticket/2793 >> and there's a ticket to add proper support: >> http://hackage.haskell.org/trac/ghc/ticket/3353 >> If it's important to you, please add a note to the ticket. >> >> >> Thanks >> Ian >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users(a)haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> >

1 0

CLDouble serialization bug in 6.10.1
by Bulat Ziganshin 17 Jul '09

17 Jul '09

Hello glasgow-haskell-users, sorry, i tested it only with 6.6 and 6.10.1. testcase available as http://www.haskell.org/bz/ldouble-bug.zip it's as simple as > foreign import ccall unsafe "" > client :: Ptr CLDouble -> IO () > > main = with 1.0 client and > void client(long double *p) > { > printf ("%f\n",(double)(*p)); > } -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

2 2

buildFdSets: file descriptor out of range
by Kazu Yamamoto 16 Jul '09

16 Jul '09

Hello, If this is not a right place to ask this question, please tell me another place to ask. I'm developing a mail server with GHC 6.10.3 on Linux. The server is running well at the beginning. But after several hours, it receives an error, "buildFdSets: file descriptor out of range". Please tell me what happened? And please suggest me how to fix this problem. Here is brief description of the server. - linked with ADNS. - complied with the -threaded option since ADNS requires it. - uses forkIO to produce threads. - does not use "deamonize" of System.Posix.Daemonize since it uses forkProcess. I execute my server as foreground process. - Because there are so many nasty SMTP clients, most SMTP connections are time out. Handles of the SMTP connections disappear, so I cannot use "hClose" to close the handles. - pushes the limit of file descriptors to 65536 with setResourceLimit. --Kazu

4 10