- Glasgow-haskell-users

Coercion among existential types
by Till Mossakowski 10 Jul '02

10 Jul '02

When implementing a tool for a heterogeneous language, I want to write a coerce function that allows me to coerce among different existential types: -- use -fglasgow-exts -package lang import Dynamic class (Typeable id, Typeable as) => Syntax id as | id -> as where parse :: id -> as data HetSyntax = forall id as . Syntax id as => HetSyntax id as class (Syntax id as, Typeable env) => StaticAnalysis id as env | id -> as, id -> env where analysis :: id -> as -> env show_env :: id -> env -> String data HetEnv = forall id as env . StaticAnalysis id as env => HetEnv id as coerce :: HetSyntax -> HetEnv coerce (HetSyntax i a) = case fromDynamic (toDyn (i,a)) :: (StaticAnalysis id as env=> Maybe (id,as)) of Just (i1,a1) -> HetEnv i1 a1 Nothing -> error "No static analysis" I have encountered the following error message: Syntax3.hs:23: Ambiguous type variable(s) `id', `as', `env' in the constraint `StaticAnalysis id as env' arising from use of `HetEnv' at Syntax3.hs:23 In a case alternative: HetEnv i1 a1 It seems that id, as, env are universally quantified. Is there a way to make them dependent on the types of i and a? Annotating i and a does not help: coerce (HetSyntax (i::id) (a::as)) = case fromDynamic (toDyn (i,a)) :: (StaticAnalysis id as env=> Maybe (id,as)) of Just (i1,a1) -> HetEnv i1 a1 Nothing -> error "No static analysis" leads to Syntax3.hs:23: Could not deduce (StaticAnalysis id as env) from the context (Syntax id as) Probable fix: Add (StaticAnalysis id as env) to the the existential context of a data constructor arising from use of `HetEnv' at Syntax3.hs:23 In a case alternative: HetEnv i1 a1 What I want is that the coercion is successful iff there is an instance of StaticAnalysis extending the given instance of Syntax. Till -- Till Mossakowski Phone +49-421-218-4683 Dept. of Computer Science Fax +49-421-218-3054 University of Bremen till(a)tzi.de P.O.Box 330440, D-28334 Bremen http://www.tzi.de/~till

1 0

functional dependency problem
by Till Mossakowski 10 Jul '02

10 Jul '02

I wish to add to Christian's question: why is it not possible to annotate v with its full type: info :: (Collects e ce, Show e) => ce -> String info (v::(Collects e ce, Show e) => ce) = show ((one v)::e) I then get the error message All of the type variables in the constraint `Collects e ce' are already in scope (at least one must be universally quantified here) In the type: (Collects e ce) => ce While checking a pattern type signature When checking the pattern: v :: forall. (Collects e ce) => ce In the definition of `info': info (v :: forall. (Collects e ce) => ce) = show ((one v) :: e) (and a similar message for the constraint Show e), which I do not understand - why should e and ce be already in scope? (I think that this question is actually independent of functional dependencies - it is about type class constraints). Till -- Till Mossakowski Phone +49-421-218-4683 Dept. of Computer Science Fax +49-421-218-3054 University of Bremen till(a)tzi.de P.O.Box 330440, D-28334 Bremen http://www.tzi.de/~till

1 0

RE: functional dependency problem
by Simon Peyton-Jones 09 Jul '02

09 Jul '02

| info :: (Collects e ce, Show e) => ce -> String | info v = show ((one v) ::e) As the error message says, and as the Haskell report says, this means info v = show ((one v) :: (forall e.e)) which is not what you meant. Haskell does not have scoped type variables, so any type variables in signatures are quantified at the signature (hence the forall). GHC does have scoped type variables, but in this case since 'e' is not mentioned in the argument or result type they are no help either. So apart from the double 'the' (thank you) GHC is behaving correctly here. Simon | -----Original Message----- | From: Christian Maeder [mailto:maeder@Informatik.Uni-Bremen.DE] | Sent: 08 July 2002 17:54 | To: glasgow-haskell-users(a)haskell.org | Subject: functional dependency problem | | | Hi, | | please consider the following example (from Mark P. Jones: | "Type Classes with Functional Dependencies" LNCS 1782, ESOP | 2000), that I've extended with a function "one": | | class Collects e ce | ce -> e where | empty :: ce | insert :: e -> ce -> ce | member :: e -> ce -> Bool | one :: ce -> e -- added just for the sake of | demonstration | | The following function was ok for GHC version 5.02.3: | | info :: (Collects e ce, Show e) => ce -> String | info v = show (one v) | | However, when I tried to mention the element type "e", that | does not occurr in the result type, I got the following error | for "show ((one | v)::e)": | | Could not deduce (Collects e ce) from the context () | Probable fix: | Add (Collects e ce) to the the type signature of an expression | arising from use of `one' at Collects.hs:11 | In an expression with a type signature: (one v) :: forall e. e | In the first argument of `show', namely `((one v) :: forall e. e)' | | (It did also not help to write "show ((one v)::Collects e ce => e)" | | Because "ce" determines the type "e" via the functional | dependency in "Collects", I think "e" should not be | changed/generalized to "forall e. e". (You may think, that | "e" should not be mentioned at all, if it is not part of the | functionality.) | | At least the behaviour of GHC seems to be inkonsistent, as it | should be possible to supply type signatures to (sub-)expressions. | | Regards Christian | | P.S. | duplicate "the"-typo in: | Add (Collects e ce) to the the type signature of an expression | ^^^^^^^ | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-| haskell-users |

2 1

RE: unsafePerformIO around FFI calls
by Simon Marlow 09 Jul '02

09 Jul '02

> > That's a nice succinct way to describe it. Another way, which boils > > down to the same thing but which is a little more concrete, is to > > ask: > > > - Does the function's result depend only on the values of its > > arguments? > > I have two problems with this alternative test: > > 1) It is sometimes slightly stricter test than necessary. > > Consider a hypothetical pair of C functions > > Foo toFoo(int); > int fromFoo(Foo); > > which satisfy the property > > fromFoo(toFoo(x)) == x > > but such that the result of toFoo does not depend on its argument. > (Perhaps toFoo allocates some memory in which to stores its result > and returns a pointer to that memory.) > > The function's result does vary independently of its values so it > fails your test. > > But if toFoo/fromFoo are the only functions on Foo, then we could > obviously have implemented the same API in Haskell with the aid of > newtype so it passes my test. Ok, if we're going to nit pick :) When talking about equality you have to restrict that to "observable equivalence" in the context of whatever abstract types you're dealing with. If a function always returns observably equivalent results when given observably equivalent arguments, then it is "safe". For example, toFoo would not be safe if you can test for equality between pointers. But if all you can do is convert it back using fromFoo, then you're ok. > 2) It fails to recognise the fact that IO actions have side effects. Well, side effects are usually only visible in the IO monad so that's ok. In your free() example, the result is either () or _|_, so the function does depend on more than just the value of the argument. I think the definition holds (but only just). For example, we normally consider a function which uses some temporary allocation on the C heap as "safe" to use from unsafePerformIO. But its side effect is visible from the IO monad by inspecting the C heap pointer. Cheers, Simon

1 0

RE: ghc and -fno-implicit-prelude
by Simon Peyton-Jones 09 Jul '02

09 Jul '02

In the upcoming 5.04 release you'll be able to do exactly that. GHC will use whatever >>= is in scope if you say -fno-implicit-prelude. Simon | -----Original Message----- | From: MR K P SCHUPKE [mailto:k.schupke@ic.ac.uk] | Sent: 09 July 2002 15:03 | To: glasgow-haskell-users(a)haskell.org | Subject: ghc and -fno-implicit-prelude | | | Can I get ghc to use a local definition of `>>=` and | return... currently | I have: | | {-# OPTIONS -fglasgow-exts -fno-implicit-prelude #-} | module Main(main) where | import qualified Prelude (Monad(..)) | import Prelude hiding (Monad(..)) | | ... Then a definition of Monad using a Premonad for return, | however when | compiling | do notation it produces an error saying it cannot deduce | (PrelBase.Monad p) | | Can I force ghc to use the definition of the Monad class I | have provided | for do notation | (IE Monad derived from Premonad derived from Prelude.Functor) | | Regards, | Keean. | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-| haskell-users |

1 0

ghc and -fno-implicit-prelude
by MR K P SCHUPKE 09 Jul '02

09 Jul '02

Can I get ghc to use a local definition of `>>=` and return... currently I have: {-# OPTIONS -fglasgow-exts -fno-implicit-prelude #-} module Main(main) where import qualified Prelude (Monad(..)) import Prelude hiding (Monad(..)) ... Then a definition of Monad using a Premonad for return, however when compiling do notation it produces an error saying it cannot deduce (PrelBase.Monad p) Can I force ghc to use the definition of the Monad class I have provided for do notation (IE Monad derived from Premonad derived from Prelude.Functor) Regards, Keean.

1 0

RE: unsafePerformIO around FFI calls
by Simon Marlow 09 Jul '02

09 Jul '02

> Hal Daume <hdaume(a)ISI.EDU> writes: > > I'm curious exactly what is "safe" and what is "unsafe" to wrap > > unsafePerformIO around when it comes to FFI calls. > > Here's a simple test: > > Could you imagine an alternative implementation of the same API in > pure Haskell? (Don't consider efficiency or effort required to write > the implementation, just whether it can be done.) > > If so, then it is ok to use unsafePerformIO and the ffi to implement > the API instead. > > If it fails that test, it is incredibly unlikely that it is ok and a > proof that it is ok is likely to be pretty complex - maybe worth a > PLDI paper or some such. That's a nice succinct way to describe it. Another way, which boils down to the same thing but which is a little more concrete, is to ask: - Does the function's result depend only on the values of its arguments? (obviously only makes sense for a top-level IO function which you want to wrap in unsafePerformIO - for a non-top-level function or expression just replace 'arguments' with 'arguments and free variables'). Cheers, Simon

2 1

unsafePerformIO around FFI calls
by Hal Daume III 08 Jul '02

08 Jul '02

I'm curious exactly what is "safe" and what is "unsafe" to wrap unsafePerformIO around when it comes to FFI calls. If there's a general discussion of this somewhere and someone could send me a pointer that would be another acceptable solution. I googled for "unsafePerformIO FFI" but nothing relevant turned up. Anyway, here's the issue at hand. I have a function which takes a value and an IO action, allocates some memory, put the value in there, executes the IO action (which is an FFI function), gets the result, deallocates the memory and then returns the rest. For instance, we have an FFI function from LAPack which computes, say, eigenvalues. Because this is from fortran and in fortran everything is by reference, the function is an IO action of (simplified) type: > maxEigenvalue :: HMatrix -> IO Double implemented using FFI. We also have the CPS function to make the HMatrix: > withMatrix :: [[Double]] -> (HMatrix -> IO Double) -> IO Double which looks basically like (I'm on vacation so I don't have the real code right now): > withHMatrix m action = > do memory <- allocate memory > hm <- write m into memory > result <- action hm > deallocate memory > return result (it's slightly more complex because i need to make it safe in the case that action throws an exception and the memory is still deallocated before the exception is re-raised.) i can then wrap these together and say: > compEig :: [[Double]] -> IO Double > compEig m = withHMatrix m maxEigenvalue so the question is: Under what circumstances is it safe to make instead: > compEig' :: [[Double]] -> Double > compEig' m = unsafePerformIO $ withHMatrix m maxEigenvalue ??? Thanks! - Hal p.s., Please continue to CC Carl as this issue came up in conversations with him -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

2 1

RE: functional dependencies - bug?
by Simon Peyton-Jones 08 Jul '02

08 Jul '02

Christian This is clearly a bug in 5.03. However, it works fine in the (about to be released) 5.04. My plan, therefore, is to add it to our regression test suite and delcare victory. If I was being totally thorough I'd find out what went wrong in 5.03, in case it's still wrong in 5.04, but I'm not going to be totally thorough! Please yell if any similar mysterious things happen. I appreciate the report. Simon | -----Original Message----- | From: Christian Maeder [mailto:maeder@Informatik.Uni-Bremen.DE] | Sent: 28 June 2002 18:09 | To: glasgow-haskell-users(a)haskell.org | Subject: functional dependencies - bug? | | | Hi, | | does anybody have experiences with "Type Classes with | Functional Dependencies" (LNCS 1782, ESOP 2000, March 200, by | Mark P. Jones)? | | I've tried the example in the above paper: | | class Collects e ce | ce -> e where | empty :: ce | insert :: e -> ce -> ce | member :: e -> ce -> Bool | | This works correctly for: | | instance Eq a => Collects a [a] where | instance Collects Char Int where | | and complains correctly for: | | instance Collects Char Int where | instance Collects Bool Int where | | with "Functional dependencies conflict between instance declarations" | | Now to my problem with a context in the class declaration: | | class Eq ce => Collects e ce | ce -> e where | empty :: ce | ... | | This works as above, but correctly complains for: | | data Stupid = Stupid -- without equality | instance Collects Bool Stupid where | | with "No instance for (Eq Stupid)". | | However, if I supply an (admittingly stupid) default | definition for "empty" within the class declaration: | | class Eq ce => Collects e ce | ce -> e where | empty :: ce | empty = error("empty") | ... | | I no longer get the above "No instance for (Eq | Stupid)"-Message, and I guess that is a bug (or a feature | that I don't understand). | | When I change the context to "Eq e" everything is fine again: | | instance Collects Stupid Int where | | complains as above. | | I don't know when (even meaningful) default definitions cause | that context conditions are not checked. In fact I noticed | this error only after I've removed a default definition just | to find out that my instance declaration were wrong that | seemed to be correct before (but instances for contexts were missing). | | Are there any other (known) pitfalls with functional dependencies? | | Regards Christian _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-| haskell-users |

2 1

Type of newForeignPtr & addForeignPtrFinalizer
by Adrian Hey 07 Jul '02

07 Jul '02

Hello, I have a feeling this may be a stupid question, but why are the types of these.. newForeignPtr :: Ptr a -> IO () -> IO (ForeignPtr a) addForeignPtrFinalizer :: ForeignPtr a -> IO () -> IO () (second arg being the finalizer) Won't a finaliser almost always take a pointer to the thing being finalised as an argument? If so it would be more convienient to have newForeignPtr.. newForeignPtr :: Ptr a -> (Ptr a -> IO ()) -> IO (ForeignPtr a) or maybe.. newForeignPtr :: Ptr a -> (ForeignPtr a -> IO ()) -> IO (ForeignPtr a) and.. addForeignPtrFinalizer :: ForeignPtr a -> (ForeignPtr a -> IO ()) -> IO () The first of these is easy to implement yourself I suppose.. myNewForeignPtr :: Ptr a -> (Ptr a -> IO ()) -> IO (ForeignPtr a) myNewForeignPtr p fin = newForeignPtr p (fin p) The second seems to require this bit of weirdness.. myNewForeignPtr :: Ptr a -> (ForeignPtr a -> IO ()) -> IO (ForeignPtr a) myNewForeignPtr p fin = do newfp <- newForeignPtr p (return ()) addForeignPtrFinalizer newfp (fin newfp) return newfp Unless I'm missing something, you have to use a pointless dummy finaliser (return ()) to get a ForeignPtr to use as the argument of the real finaliser. The reason I ask is I've been trying to use C2HS recently to produce a Haskell binding to GNU plot library, and have had to do something very similar. The relevant bits of .chs file being.. -- Haskell: newtype Plotter = Plotter (ForeignPtr Plotter) {#pointer *plPlotter as Plotter foreign newtype#} -- Haskell: newtype PlotterParams = PlotterParams (ForeignPtr PlotterParams) {#pointer *plPlotterParams as PlotterParams foreign newtype#} -- Destructor for the plPlotter type. -- C proto: int pl_deletepl_r (plPlotter *plotter); -- Haskell: deletePlotter :: Plotter -> IO () {#fun unsafe pl_deletepl_r as deletePlotter {id `Plotter'} -> `()' -- id as marshaller?? #} -- Create a new X Plotter -- C proto: plPlotter* new_x_plotter (plPlotterParams* plotter_params); -- Haskell: newXPlotter :: PlotterParams -> IO Plotter -- newXPLotter'_ :: PlotterParams -> IO (Ptr Plotter) {#fun unsafe new_x_plotter as newXPlotter {id `PlotterParams'} -> `Plotter' marshalPlotter * #} marshalPlotter :: Ptr Plotter -> IO Plotter marshalPlotter p = do foreignPlotter <- newForeignPtr p (return ()) let plotter = Plotter foreignPlotter addForeignPtrFinalizer foreignPlotter (deletePlotter plotter) return plotter I suppose the thing that's worrying me most is will this work? (I don't have enough done yet to find out). It seems overly complicated to me, but I can't see any alternative to this complexity. Am I using C2HS right? Have I missed something obvious? Thanks -- Adrian Hey

1 0