August 2004 - Glasgow-haskell-users

RE: Dynamic loading problem
by Simon Marlow 18 Feb '05

18 Feb '05

On 30 April 2004 11:26, Duncan Coutts wrote: > Could someone remind me what the remaining issues are in getting ghc > to build Haskell modules/packaged into unix .so shared libraries? > > As I recall it seems to nearly work. Andre Pang got them to load and > function but it was a bit fragile and the rts would complain after a > short while: > http://www.mail-archive.com/glasgow-haskell-users@haskell.org/msg03923.h tml It might be possible to do this, but only if you want to do dlopen()-style linking at runtime. Linking a haskell binary against Haskell .so libraries still isn't possible - I had another look at this recently, and although one of the obstacles has been removed, there are others (details available on request). Any remaining issues to do with dlopen()ing a Haskell .so library are probably to do with CAFs. The dynamically loaded code needs to call newDynCAF() instead of newCAF() in a CAF's entry code - this is normally arranged by the RTS linker, but for a .so you'll have to do it some other way, like getting the compiler to emit the different call, or doing some CPP magic (but only for -fvia-C). Any reasonable patches to implement this will be incorporated. Oh, and strictly speaking we should run the __stginit_Foo() function from each dynamically loaded module. But the RTS linker still doesn't do this. Cheers, Simon

4 3

RE: Double -> CDouble, realToFrac doesn't work
by Simon Peyton-Jones 05 Nov '04

05 Nov '04

| Hmmm, this is a little bit of a dark corner in the H98 report, but there are | probably other people on this list who know better than me. :-] The problem | is that 'realToFrac' is defined as 'fromRational . toRational', so the first | question is: How is 'toRational' supposed to handle NaN? One thing coming to | my mind is '0 :% 0', but this is normally a value which can't be constructed. | So the next question is: Would this be allowed? +Infinity and -Infinity could | be represented similarly then ('1 :% 0' and '(-1) :% 0'), and 'fromRational' | could handle these values specially. But I can't believe that this has been | discussed for the first time. SPJ? Malcolm? I don't recall a discussion about this, and a quick search in my mail archive didn't turn up anything except the enclosed from George Russell. I'm pretty ignorant about the dark corners of numerics, but it does seem bad that passing through Rational loses information. Perhaps the Report should specify normalised representations for +Inf, -Inf and NaN as Rationals (1:%0, -1:%0, and 0:%0 seem like plausible candidates). If someone wants to try this out, and send us a patch for the Rational library, we could incorporate it. And so far as the report goes, perhaps the Errata could contain a note identifying the issue, and suggesting a solution. It's a bit late to *specify* a solution unless we are really sure about it. Simon -----Original Message----- From: George Russell [mailto:ger@informatik.uni-bremen.de] Sent: 25 February 2000 10:19 To: glasgow-haskell-users(a)haskell.org Subject: Floating-point nitpicking: floor(Inf) and floor(NaN) floor(Inf) and floor(NaN) do not appear to be defined in Standard Haskell. (They both come down to "properFraction" which is only defined for Ratio.) This differs from (for example) the Standard ML Basis Library, where it is specified that floor(Int) should raise Overflow and floor(NaN) should raise Domain. Hence Hugs and GHC do different things. Hugs returns floor(Inf) = 0 and floor(NaN) = 0 GHC returns floor(Inf) = very very large integer and floor(NaN) = even larger integer. (This is because the GHC implementation of properFraction simply ignores the case of Inf/NaN and treats the artificially high exponent encoded in those floating-point numbers as if it were a real one.) My own opinion is that Standard ML is right here and that floor(x) should raise an exception (In Haskell terms, fail) when x does not correspond to a real number. | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Sven Panne | Sent: 08 August 2004 17:02 | To: Hal Daume III | Cc: GHC Users Mailing List; Malcom Wallace | Subject: Re: Double -> CDouble, realToFrac doesn't work | | Hal Daume III wrote: | > [...] | > Prelude Foreign.C> (0 :: CDouble) / 0 | > NaN | > Prelude Foreign.C> (0 :: Double) / 0 | > NaN | > Prelude Foreign.C> realToFrac ((0 :: Double) / 0) :: CDouble | > -Infinity | > | > yikes! the NaN got turned into a -Infinity!!! | > | > aside from manually checking for 'strange' Double/CDouble values and | > wrapping realToFrac, is there a better way? also, does this count as a | > bug? | | Hmmm, this is a little bit of a dark corner in the H98 report, but there are | probably other people on this list who know better than me. :-] The problem | is that 'realToFrac' is defined as 'fromRational . toRational', so the first | question is: How is 'toRational' supposed to handle NaN? One thing coming to | my mind is '0 :% 0', but this is normally a value which can't be constructed. | So the next question is: Would this be allowed? +Infinity and -Infinity could | be represented similarly then ('1 :% 0' and '(-1) :% 0'), and 'fromRational' | could handle these values specially. But I can't believe that this has been | discussed for the first time. SPJ? Malcolm? | | When you compile the stuff above with optimizations on, you get what you've | expected, thanks to RULES which shortcut the route via Rational completely. | | Cheers, | S. | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

4 3

HaXml 1.12 <-> HXmlToolbox 4.01 incompatibility?
by Jan Scheffczyk 30 Aug '04

30 Aug '04

Hi all, I try to use HaXml and HXmlToolbox together with GHC 6.2.1. I am, however, a bit confused since some versions seem to "influence" each other. So far I tried: HaXml 1.11 + HXmlToolbox 4.01 and HaXml 1.12 + HXmlToolbox 4.01. While HaXml 1.11 appears to work fine with HXmlToolbox 4.01, I get some strange errors for the combination 1.12 + 4.01 when using HXmlToolbox. You find examples below. Any ideas? Best regards, Jan --------------------------------------------------------- All examples below are for the combination HaXml 1.12 + HXmlToolbox 4.01: The TreeVisualization from HXmlToolbox: ghci -package hxt TreeVisualisation.hs Loading package base ... linking ... done. Loading package haskell98 ... linking ... done. Loading package lang ... linking ... done. Loading package unix ... linking ... done. Loading package posix ... linking ... done. Loading package network ... linking ... done. Loading package net ... linking ... done. Loading package parsec ... linking ... done. Loading package hxt ... linking ... done. Compiling Main ( TreeVisualisation.hs, interpreted ) TreeVisualisation.hs:11: Failed to find interface decl for `AssocList' from module `AssocList' TreeVisualisation.hs:11: Failed to find interface decl for `AssocList' from module `AssocList' tcLookup: `AssocList' is not in scope When checking kinds in `AssocList String String' In the type synonym declaration for `Attributes' Failed, modules loaded: none. ----------------- Invoking ghci with just -package hxt appears to work at first sight, but then: ghci -package hxt ... Loading package hxt ... linking ... done. Prelude> :b AssocList data FM k a = adjust :: forall a k. (Eq k) => (a -> a) -> k -> FM k a -> FM k a adjustAll :: forall a k. (Eq k) => (a -> a) -> k -> FM k a -> FM k a count :: forall k a. (Eq k) => FM k a -> k -> Int delete :: forall k a. (Eq k) => k -> FM k a -> FM k a deleteAll :: forall k a. (Eq k) => k -> FM k a -> FM k a deleteSeq :: forall seq :: (* -> *) k a. (Eq k, Sequence.Sequence seq) => seq k -> FM k a -> FM k a .... Strange, thats not the AssocList from HXmlToolbox (see below)! Prelude> :b HdomParser Failed to find interface decl for `AssocList.AssocList' from module `AssocList' Failed to find interface decl for `AssocList.addEntries' from module `AssocList' Failed to find interface decl for `AssocList.addEntry' from module `AssocList' Failed to find interface decl for `AssocList.delEntries' from module `AssocList' Failed to find interface decl for `AssocList.delEntry' from module `AssocList' Failed to find interface decl for `AssocList.hasEntry' from module `AssocList' Failed to find interface decl for `AssocList.lookup1' from module `AssocList' Failed to find interface decl for `AssocList.lookupDef' from module `AssocList' Failed to find interface decl for `AssocList.AssocList' from module `AssocList' Failed to find interface decl for `AssocList.AssocList' from module `AssocList' tcLookup: `AssocList.AssocList' is not in scope When checking kinds in `AssocList.AssocList GHC.Base.String GHC.Base.String' In the type synonym declaration for `XmlTreeTypes.Attributes' -------------------------------------------------------------------- Example for the combination HaXml 1.11 + HXmlToolbox 4.01 ghci -package hxt Loading package base ... linking ... done. Loading package haskell98 ... linking ... done. Loading package lang ... linking ... done. Loading package unix ... linking ... done. Loading package posix ... linking ... done. Loading package network ... linking ... done. Loading package net ... linking ... done. Loading package parsec ... linking ... done. Loading package hxt ... linking ... done. Prelude> :b AssocList type AssocList k v = [(k, v)] addEntries :: forall k v. (Eq k) => AssocList k v -> AssocList k v -> AssocList k v addEntry :: forall k v. (Eq k) => k -> v -> AssocList k v -> AssocList k v delEntries :: forall k v. (Eq k) => [k] -> AssocList k v -> AssocList k v delEntry :: forall k v. (Eq k) => k -> AssocList k v -> AssocList k v hasEntry :: forall k v. (Eq k) => k -> AssocList k v -> Bool lookup1 :: forall k e. (Eq k) => k -> AssocList k [e] -> [e] lookupDef :: forall v k. (Eq k) => v -> k -> AssocList k v -> v Prelude>

1 0

RE: Problem with Unboxed Types
by Simon Peyton-Jones 27 Aug '04

27 Aug '04

Just to be sure, I've just compiled and run this code with GHC 6.2.1, on a Linux system. I can't account for your difficulty I'm afraid. Simon {-# OPTIONS -fglasgow-exts #-} module Main where import GHC.Exts showUnboxedInt :: Int# -> String showUnboxedInt n = (show $ I# n) ++ "#" main = print (showUnboxedInt 3#) | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Jorge Adriano Aires | Sent: 27 August 2004 02:55 | To: glasgow-haskell-users(a)haskell.org | Subject: Problem with Unboxed Types | | Hello, | I'd like to try using Unboxed types, but I always get a "parse error on input | `#'" error. To make sure I wasn't making some mistake I tried the example in | the wiki: | | http://www.haskell.org/hawiki/UnboxedType | -------------------------------------------------------- | module Main where | import GHC.Exts | | showUnboxedInt :: Int# -> String | showUnboxedInt n = (show $ I# n) ++ "#" | -------------------------------------------------------- | | Even tried adding fglasgow-exts, nothing works though. I'm using GHC 6.2.1 on | a SuSE 8.2 system (glibc 2.3) installed using the available RPMs. Any idea? | | Thanks in advance, | J.A. | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

2 1

Problem with Unboxed Types
by Jorge Adriano Aires 27 Aug '04

27 Aug '04

Hello, I'd like to try using Unboxed types, but I always get a "parse error on input `#'" error. To make sure I wasn't making some mistake I tried the example in the wiki: http://www.haskell.org/hawiki/UnboxedType -------------------------------------------------------- module Main where import GHC.Exts showUnboxedInt :: Int# -> String showUnboxedInt n = (show $ I# n) ++ "#" -------------------------------------------------------- Even tried adding fglasgow-exts, nothing works though. I'm using GHC 6.2.1 on a SuSE 8.2 system (glibc 2.3) installed using the available RPMs. Any idea? Thanks in advance, J.A.

1 0

Extensible Serialization class with type classes
by Simon David Foster 26 Aug '04

26 Aug '04

I've been trying to put together a type-class based serialization (XML) for types in GHC. Essentially the serializer class takes the form class Seriliazer a where serialize :: a -> XmlFilter This works very well, but I then wanted to make this system extensible, so that for example for types which are also typed by equivalent XSD Types (i.e. types with constraint XSDType a => a) could have their type-data encoded into the tree. The problem is, it seems to me there is no viable method of adding an extra parameter function to the serialiaze function, which will enforce extra constraints on a and allow recursive serialization. Obviously simply passing a function (C a => a -> XmlFilter) doesn't work, since the type a becomes unified to the top-level type and so can't be passed down. The second attempt was to add another type class called Hook, with two type variables; the first being a dummy type and the second the variable to represent the type being serialized; class Hook a t where hookAttr :: t -> a -> [(String, String)] hookElem :: t -> a -> [XmlFilter] and rewriting serialize as class Hook a t => Serializer a t where serialize :: t -> a -> XmlFilter Then, passing the dummy type to the serialized function as the t value would force the extra constraints from its Hook instance on a. This method though doesn't really work that well; first of all it requires undecidable-instances and second each new instance on serialize requires a humongous context since each type used directly and indirectly needs inferring as an instance of Hook. The idea was that this code could be generated automatically, and that really makes it too difficult to do. The Third attempt was to use existential types to encapsulate a constrained polymorphic type and use Typeable + Generics to choose between a number of functions. This though doesn't work either, since each value down the type tree needs to be of the appropriate monomorphic existentially quantified type since polymorphic types aren't Typeable. I seem to have pretty much exhausted every option for building this extensible Serializer, and so my question is this; is there anyway of passing a hook function to the serializer class instances, such that it will remain polymorphic down the serialization tree but will also enforce the constraints on the input parameter on the type being serialized. For example is it every likely to be possible to reify polymorphic types? -Si.

2 2

RE: GHC and MPTCs
by Simon Peyton-Jones 26 Aug '04

26 Aug '04

Your problem is that next_state :: forall s v. VertexState s v => s -> s So an application of next_state to an argument of type sty will require the constraint VertexState sty v but that says NOTHING about v. It's a bit like calling a function with type forall a b. Foo a => b -> b Anyway, I think what you want is a functional dependency class VertesState s v | s -> v Then fixing s will fix v, which is what you want I think Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Ketil Malde | Sent: 25 August 2004 14:45 | To: glasgow-haskell-users(a)haskell.org | Subject: GHC and MPTCs | | | Hi, | | I recently tried to do the following code: | | class VertexState s v where | new_point :: s -> v -> v -> v | next_state :: s -> s | | -- interleave :: (VertexState s a) => s -> [a] -> [a] -> [a] | interleave s (t:ts) (b:bs) = | new_point s t b : interleave (next_state s) bs (t:ts) | interleave _ [] [b] = [] | | Firstly, GHC doesn't deal all too gracefully with this if the type | signature is uncommented, it tells me: | | Could not deduce (VertexState s v) | from the context (VertexState s a) | arising from use of `next_state' at Grid.lhs:25 | Probable fix: | Add (VertexState s v) to the type signature(s) for `interleave' | | Unfortunately, doing the probable fix just results in a new request | for (VertexState s v1), and so on. | | I suppose the real problem is that GHC can't decide from next_state | that it is supposed to use exactly this instance of VertexState, is | there a good way to do that without adding an explicit dummy parameter | of type v? | | (I really would like to be able to have instances with the same s but | different v's, which I think adding functional deps would make | difficult.) | | -kzm | -- | If I haven't seen further, it is by standing in the footprints of giants | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

Re: GHC and MPTCs
by MR K P SCHUPKE 25 Aug '04

25 Aug '04

Try type annotations: new_point (s::s) t b : interleave (next_state s::s) bs (t:ts) Keean.

2 1

RE: Is it possible to load bindings into ghci
by Simon Marlow 25 Aug '04

25 Aug '04

On 25 August 2004 15:06, Andreas Marth wrote: > Later Tomasz Z. >> How about this: >> >>> def . readFile >> :. C.hs >> >> I guess I got there first ;) > > That works great! And you can even put the ":def . readFile" in the > .ghci File! > So now I start ghci with "ghci MyFile" wait until it's finished and do > ":. all_the_stuff_I_need_in_a_file" > and every thing is fine! Yes, that's a neat trick. I'm annoyed I didn't think of it, especially since I'm the one who invented :def. Duh :-) Cheers, Simon

2 1

RE: Is it possible to load bindings into ghci
by Simon Marlow 25 Aug '04

25 Aug '04

On 24 August 2004 12:47, Andreas Marth wrote: > At the moment it happens that I use an unfinished program with ghci. > And each time I start GHCi, I have to introduce the same bindings aka > 'cont <- readFile "myFile"' ... > Is there a way to define them once in a File and then point GHCi to > it? (I need somme of the functions in the unfinished program so it has > to be after reading the program file.) Like the '.' command in /bin/sh? Yes, we ought to have something like that. I'll get around to it at some point, unless anyone gets there first. Cheers, Simon

3 4