Re: [Haskell-cafe] Polymorphic algebraic type constructors

2004-06-23 Thread MR K P SCHUPKE
f (i:is) = even i : f is f e = e This still makes perfect sense to me... you see the let binding: let [EMAIL PROTECTED] = e has no additional information about the type of [] so it must be fully polymorphic. if the function binding we know typeOf e == typeOf (i:is) and that i is a member

RE: [Haskell-cafe] Ord (IORef a)?

2004-06-23 Thread Simon Marlow
On 23 June 2004 03:53, John Meacham wrote: Yeah, i forgot about the GC moving things around. actually, if the GC could be coaxed to move things around, but never change the relative order of IORefs (like a compacting collector), then the address could still be used for Ord and Eq. This is a

RE: [Haskell-cafe] How to use QSem?

2004-06-23 Thread Simon Marlow
On 22 June 2004 21:44, S. Alexander Jacobson wrote: The GHC documentation on QSem is very sparse. I would like to give a thread exclusive access to a resource. My *guess* based on the documentation is that I can create an exclusive lock using: logSem - newQSem 1 If the maximum

Re: [Haskell-cafe] Polymorphic algebraic type constructors

2004-06-23 Thread Adrian Hey
On Wednesday 23 Jun 2004 10:46 am, MR K P SCHUPKE wrote: f (i:is) = even i : f is f e = e This still makes perfect sense to me... you see the let binding: let [EMAIL PROTECTED] = e has no additional information about the type of [] so it must be fully polymorphic. if the function

Re: [Haskell-cafe] Polymorphic algebraic type constructors

2004-06-23 Thread MR K P SCHUPKE
What you are suggesting - whilst it seems reasonable requires a fundamental change to the type system. At the moment [] signifies an empty list of type 'a' ... what you are suggesting requires [] to have a different type from [a]... This means a simple case statement : case a of

Re: [Haskell-cafe] Polymorphic algebraic type constructors

2004-06-23 Thread Adrian Hey
On Wednesday 23 Jun 2004 12:40 pm, MR K P SCHUPKE wrote: What you are suggesting - whilst it seems reasonable requires a fundamental change to the type system. At the moment [] signifies an empty list of type 'a' ... what you are suggesting requires [] to have a different type from [a]... This

Re: [Haskell-cafe] Polymorphic algebraic type constructors

2004-06-23 Thread MR K P SCHUPKE
Adrian Hey wrote: I think all occurences of [] have type forall a. [a] The case expression.. case a of (a':as) - expr1 [] - expr2 Should be typed as if written.. case a of (a':as) - let a=(a':as) in expr1

Re: [Haskell-cafe] Polymorphic algebraic type constructors

2004-06-23 Thread Philippa Cowderoy
On Wed, 23 Jun 2004, Adrian Hey wrote: I think all occurences of [] have type forall a. [a] The case expression.. case a of (a':as) - expr1 [] - expr2 Should be typed as if written.. case a of (a':as) - let

Re: [Haskell-cafe] Polymorphic algebraic type constructors

2004-06-23 Thread Philippa Cowderoy
On Wed, 23 Jun 2004, Philippa Cowderoy wrote: Not much of use. Er, I meant to cancel that upon re-reading and following things but ^X is next to ^C :-( -- [EMAIL PROTECTED] ___ Haskell-Cafe mailing list [EMAIL PROTECTED]

Re: [Haskell-cafe] Polymorphic algebraic type constructors

2004-06-23 Thread Graham Klyne
Well, I can live with it well enough, but I wanted to make sure I wasn't overlooking something simple (which it appears I'm not). #g -- At 13:38 22/06/04 +0100, Adrian Hey wrote: I think this was the topic of my very first post to Haskell mailing list, many years ago..

atomic MVar overwrite (was RE: [Haskell-cafe] How to use QSem?)

2004-06-23 Thread S. Alexander Jacobson
Ah, that worked. Thank you. The MVar documentation is also very brief. I would also like to overwrite the contents of an MVar atomically regardless of whether it is full or empty. I am current using. overWrite mvar val = tryTakeMVar mvar putMVar mvar val But it is not atomic :-( The lib

Re: [Haskell-cafe] Polymorphic algebraic type constructors

2004-06-23 Thread Ralf Laemmel
Graham Klyne wrote: If I have a polymorphic algebraic type (T a) with several type constructors, only one of which actually references the type parameter, is there any way to express type conversion for the type-parameter-independent constructors without actually mentioning all the

RE: atomic MVar overwrite (was RE: [Haskell-cafe] How to use QSem?)

2004-06-23 Thread Simon Marlow
On 23 June 2004 17:13, S. Alexander Jacobson wrote: Ah, that worked. Thank you. The MVar documentation is also very brief. I would also like to overwrite the contents of an MVar atomically regardless of whether it is full or empty. I am current using. overWrite mvar val =

RE: atomic MVar overwrite (was RE: [Haskell-cafe] How to use QSem?)

2004-06-23 Thread S. Alexander Jacobson
Basically, what I want is a tryReadSampleVar function. Or, if we stick with MVars, I don't want another thread to operate between the tryTakeMVar and the putMVar. In particular, I don't want another thread to believe (mistakenly) that the mvar is empty when it is simply being updated. I suppose

Re: [Haskell-cafe] Polymorphic algebraic type constructors

2004-06-23 Thread Graham Klyne
Interesting, I think... If I understand correctly, the use of 'just' does indeed make it rather too untyped for my taste. It's been a while since I looked at the boilerplate work, but looking at your code I think it depends on gmapQ of the polymorphic value to be converted. Does your generic

Re: [Haskell-cafe] Polymorphic algebraic type constructors

2004-06-23 Thread Adrian Hey
On Wednesday 23 Jun 2004 2:08 pm, MR K P SCHUPKE wrote: If I want a let binding I can write one. The trouble with this is that a sub-optimal (I don't like to use the word naive) implementation will actually create a new heap construction, rather than re-use the one it knows (or should know) it

Re: [Haskell-cafe] Polymorphic algebraic type constructors

2004-06-23 Thread John Meacham
There is a fundamental problem with assuming all []'s are equal even if they are empty lists of different things. mainly, that they arn't! see ; ghci Prelude print ([]::[Int]) [] Prelude print ([]::[Char]) Remember, in haskell, values may depend on types. Just because the type is not