July 2002 - Glasgow-haskell-users

�ǯu��X�X��
by p_wqb1p22lkts＠thestandardeurope.com 11 Jul '02

11 Jul '02

¶Ç¯už¹œX¥X°â §ÚŠ³¥_°Ï02_¶}ÀY¶Ç¯už¹œX¡AŠ@¬°77270µ§ ¬O§Ú±qŠUÓŠP·~€œ·|¡B¹qžÜÃ¯¡B¶À¶¡BŒx«H©Ò¡B ºô»Úºôžô¡A¥úºÐ€ù...µ¥µ¥¡A žgŠ~²Ö€ë€@µ§€@µ§¥Ž€JŠ¬¶°€UšÓªº¡A¶O€F«Ü€jªº¥\€Ò¡C ¥úªá¿ú¶RŒx«H©Ò¥Xªºªº¥U€l¡AŽNªá€F€£€Ö¿ú¡A ŠAžg¹L²Îp€èªkŸã²z¡A©Ò¥HšSŠ³¥ôŠó€@µ§¬O«œÆªº¡A šÃžg¹L¹ê»Úµo°eŽúžÕ¡AŠAç°£±ŒµL®Äªºž¹œX¡A ©Ò¥HšC€@µ§šì4€ë©³¬°€î¡A³£¥i¥Hµo°e¡C ®ÚŸÚžgÅç¡AŽX¥G©ÒŠ³02_¶}ÀYªº¶Ç¯u¡A ³£€wŠ¬¶°Šb³ožÌ€F¡A±qšä¥LšÓ·œ¡A€]€£€Ó®e©öŠA§äšì·sªº¡C ŠpªG±zŠ³¿³œìÁÊ¶R¡A§ÚÄ@·N¥H3000€ž€ÀšÉ¡C ŸH€p©j tel: 02-27492314

1 0

chat multitasking e suola di sesso live
by jusy 11 Jul '02

11 Jul '02

http://www.ragazze-sexy.tv La boutique dell'eros si � arricchita di una chicca: nuovissima chat multisking, con riprese aeree multicam, con pi� inquadrature, e maggiore risoluzione. New entry anche di ragazze internazionali, per la chat multilingue. Scuola di sesso live con lezioni per allungamento del pene e individuazione punto "G". http://www.ragazze-sexy.tv

1 0

type classes / ghci
by Keean 10 Jul '02

10 Jul '02

I have found what is either a problem in ghc/ghci or a problem in my understanding... either way if someone could point out whats wrong I would be very grateful. I am experimenting with monad-transformers, and am tying to define a class to allow a run function to be overloaded. The program layers two monads on top of the IO monad, a state monad-transformer, and an error monad-transformer. If I define a set of untyped functions: unFC (FC x) = x -- run a forward composed monad unBC (BC x) = x -- run a backward composed monad unSTM (STM x) = x -- run a monad composed with a State monad-transformer I then used ghci to derive the type for these functions... unFC :: forall m n a . (Monad m,Monad n) => FComp m n a -> n (m a) unBC :: forall m n a . (Monad m,Monad n) => BComp m n a -> m (n a) unSTM :: forall s m a . (Monad m) => StateT s m a -> s -> m (a,s) the program still passes type checking with these types added. next I defined a type class: class Composed c where run :: c and some instances: instance (Monad m,Monad n) => Composed (FComp m n a -> n (m a)) run = unFC instance (Monad m,Monad n) => Composed (BComp m n a -> m (n a)) run = unBC instance (Monad m) => Composed (StateT s m a -> s -> m (a,s)) run = unSTM However when I compile now, replacing: unFC (unSTM test (0::Int)) with run (run test (0::Int)) I now get an error: no instances for (Composed (t -> IO t1),Composed (StateT Int ErrorIO Int -> Int -> t)) Regards, Keean.

1 0

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