April 2006 - Haskell-prime

need help again [loading bitmaps]
by enache alex 22 Apr '06

22 Apr '06

hello again ; I am writing again to ask you if you can please show me an example of loading a bitmap on a window ; I tried tu use the bitmap function from Graphics.Rendering.OpenGL.GL.Bitmap but it gives me an error ; I've called the function like this : bmp <- bitmap (Size (100,100)) (Vertex2 (0::GLfloat) 0) (Vector2 0 0 ) (Ptr "C:\1.bmp") ; and it sais ERROR file:.\ball.hs:43 - Undefined data constructor "Ptr" pls help ; I want to make my game look a little better ; thanks again ; --------------------------------- Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2¢/min or less.

2 1

need help please[HOpenGL]
by enache alex 22 Apr '06

22 Apr '06

hello ; I am learning to use to HOpenGL to complete an asignement for next week and I have some trouble ; I have found a tutorial on the internet ; in that tutorial it was an example of the Rubik's Cube ; anyway ; in that example it was used a function called matrixExcursion ; and when I try to run the example it sais that : " ERROR file:.\RubikFace.hs:9 - Undefined variable "matrixExcursion" " I don't know what to do ; please help ; I need to know immediatly how to fix this problem ; thanks for your time in reading this , and hope to hear from you soon ; I wish you all the best --------------------------------- How low will we go? Check out Yahoo! Messengers low PC-to-Phone call rates.

2 1

Class System status
by Stephanie Weirich 17 Apr '06

17 Apr '06

I've been working on a summary page for the class system proposals (http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/wiki/ClassSystem) similar in spirit to the Concurrency page that Simon Marlow has been developing. This page is important because it lists all of the proposals not related to MPTCs as well as trying to capture the big picture about where we stand with respect to MPTCs. I've been trying to not duplicate text that appears elsewhere in the wiki, but just provide a consistent picture of the state of the discussions on the mailing list. Please take a look at this page and help me fill it out. In particular, I've been trying to take a pulse of where we stand on some of these issues, and some of you may not agree! Tell me if I'm off the wall. Also, I've (mostly) concentrated on issues that have tickets, so I may have missed some issues that were only discussed in the mailing list. Please let me know if there is anything I've forgotten. Thanks, Stephanie

1 0

A modest proposal
by Hoan Ton-That 16 Apr '06

16 Apr '06

Hello Happy Haskellers, I would like to humbly suggest that we replace all Int functions in the prelude with the corresponding generic ones. These are: drop, take, length, splitAt, replicate and (!!). If at all possible it would be grand if we replaced the ones in Data.List (such as elemIndex) and other modules too! Irradicate Irritating Ints! There I said it! Hoan

4 3

network I/O
by Johan Henriksson 15 Apr '06

15 Apr '06

hello, I don't think I have meat enough to make a proposition but at least I would like to give a heads up. I find the current network I/O to be very hard to use for anything more complicated like a server. Recently I ended up tossing out all networking into C through FFI which works but is very inconvenient. The problem is that the API does not support exceptions in a very good manner but rather seems to have been written for very simple programs for an "ideal world": * Timeouts are messy to implement * Blocking is hard to avoid if FFI is used concurrently (requires system threads) * I do not know how well haskell scales compared to traditional languages like C with select() but this is am important aspect I guess the most reasonable solution (doesn't break current programs) is a new lower level interface that has been better planned to play well with threads and FFI. since these topics are already on your table, I think it would be good timing to look over the sockets interface. - Johan Henriksson

2 1

FDs and confluence
by Ross Paterson 15 Apr '06

15 Apr '06

(see the FunctionalDependencies page for background omitted here) One of the problems with the relaxed coverage condition implemented by GHC and Hugs is a loss of confluence. Here is a slightly cut-down version of Ex. 18 from the FD-CHR paper: class B a b | a -> b class C a b c | a -> b instance B a b => C [a] b Bool Starting from a constraint set C [a] b Bool, C [a] c d, we have two possible reductions: 1) C [a] b Bool, C [a] c d => c = b, C [a] b Bool, C [a] b d (use FD on C) => c = b, B a b, C [a] b d (reduce instance) 2) C [a] b Bool, C [a] c d => C a b, C [a] c d (reduce instance) The proposed solution was to tighten the restrictions on instances to forbid those like the above one for C. However there may be another way out. The consistency condition implies that there cannot be another instance C [t1] t2 t3: a substitution unifying a and t1 need not unify b and t2. Thus we could either 1) consider the two constraint sets equivalent, since they describe the same set of ground instances, or 2) enhance the instance improvement rule: in the above example, we must have d = Bool in both cases, so both reduce to c = b, d = Bool, B a b More precisely, given a dependency X -> Y and an instance C t, if tY is not covered by tX, then for any constraint C s with sX = S tX for some substitution S, we can unify s with S t. We would need a restriction on instances to guarantee termination: each argument of the instance must either be covered by tX or be a single variable. That is less restrictive (and simpler) than the previous proposal, however. Underlying this is an imbalance between the two restrictions on instances. In the original version, neither took any account of the context of the instance declaration. The implementations change this for the coverage condition but not the consistency condition. Indeed the original form of the consistency condition is necessary for the instance improvement rule.

7 20

Re: Defaults for superclass methods
by Cale Gibbard 14 Apr '06

14 Apr '06

On 14/04/06, Dave Menendez <dave(a)zednenem.com> wrote: > The tricky part is dealing with multiple subclasses. > > For example, > > class Functor f where > fmap :: (a -> b) -> f a -> f b > > class Functor f => Monad f where > ... > fmap = liftM > > class Functor f => Comonad f where > ... > fmap = liftW > > newtype Id a = Id a > > instance Functor Id > instance Monad Id > instance Comonad Id > > Which default gets used for fmap? The simple solution is to make it an error, and force the programmer to define an instance of Functor as soon as that happens. Most of the problems seem to happen in mostly-linear hierarchies anyway.

1 0

RE: Defaults for superclass methods
by Simon Marlow 14 Apr '06

14 Apr '06

On 11 April 2006 11:08, Ross Paterson wrote: > On Tue, Apr 11, 2006 at 11:03:22AM +0100, Simon Marlow wrote: >> This is a rather useful extension, and as far as I can tell it >> doesn't have a ticket yet: >> >> http://www.haskell.org//pipermail/libraries/2005-March/003494.html >> >> should I create a ticket? Is there any reason it might be hard to >> implement? > > There are a range of proposals, but none of them are implemented. > Wouldn't that rule them out for Haskell'? If it's not clear which is the right way to go, then yes I guess that does rule it out. Could you summarise the proposals? If there was a clear winner, and it was easy enough to implement, perhaps we can knock up a prototype in time. The reason being I just hit a case where this would be useful, while trying to find a nice way to express extensible exceptions. Cheers, Simon

4 3

collecting requirements for FDs
by Ross Paterson 13 Apr '06

13 Apr '06

The favourite customer for FDs has been the monad transformer library. (There are at least two versions, but they have the same requirements.) In this library, all the dependencies are full, i.e. involve all (both) the arguments of the class, e.g. class (Monoid w, Monad m) => MonadWriter w m | m -> w Instances of these classes are of two kinds: 1) Base cases: the range argument is a variable that occurs in the domain argument, e.g. instance (Monoid w, Monad m) => MonadWriter w (WriterT w m) 2) Inductive definitions: the range argument is a variable that is determined by variables in the domain argument via an FD (on the same class) in the context of the instance, e.g. instance (Error e, MonadWriter w m) => MonadWriter w (ErrorT e m) What other libraries should Haskell' support, and what are their requirements?

6 6

RE: deeqSeq proposal
by Simon Peyton-Jones 13 Apr '06

13 Apr '06

| Well, my worry was partly about the suggested version of deepSeq that | would not diverge on circular structures (since circular structures | are just one way to implement "infinite" data structures). Dynamic idempotence is not the same as detecting circular structures. Deepseqing a circular structure should definitely diverge, as it would as if it was infinite. Idempotence changes the operational behaviour, but not the denotational behaviour. So that part of the worry is ok. But since the dynamic-idempotence operational behaviour is (as I understand the proposal) the whole point, it's true that the implementation would be constrained. In the same kind of way that we expect call-by-need rather than call-by-name. S

4 5