- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] Adding Ord constraint to instance Monad Set?
by MR K P SCHUPKE 31 Mar '04

31 Mar '04

>My intention was that the context before a data constructor shall mean that >the variable (a) shall be constrained only in the type of the constructor >function, not in the type definition. Okay, functional laguages have the notion that binding a variable is true for all time (like in mathematics)... Therefore if "a" is "1" then it has type Integer - forever. In this case the type of a in the first definition is "forall a . Num a". This is true for all references to a where we mean the same a. Because a is on the left-hand-side of the equals we assume all a's on the right are the same (it is the only rational choise) and hence we end up with two different types for a single variable. you could say something like (this doesn't work by the way) data Either a = (forall a . Num a => Left a) (forall a . Ord a => Right a) But here the a in each set of brackets has nothing to do with the a on the left hand side. This is different from: (data Either a = Num a => Left a | Ord a => Right a) where it is clear a == a but Ord a /= Num a Doing anything different would break the scoping rules for variables, and it is much more important IMHO to keep these consistant. Good languages are: Consistant, Symmetric, and Complete. Regards, Keean.

1 0

Re: [Haskell-cafe] Adding Ord constraint to instance Monad Set?
by MR K P SCHUPKE 31 Mar '04

31 Mar '04

> data Either a =3D > Num a =3D> Left a > Ord a =3D> Right a This is a mistake because the same variable is being constrained in two different ways. The only way both constrains can be satisfied is if a is both in Num and Ord. This can be written: data (Num a,Ord a) => Either a = Left a | Right a Which makes it a lot clearer that the constaints apply to both the Left and Right constructor. You have to remember that a is a polymorphic variable... now the first line [Num a => Left a] says that a has the type (forall a . Num a) but the second line [Ord a => Right a] says a has the type (forall a . Ord a) These are not the same type, so when they are combined (remember a scopes over the whole type definition) there is a type error because: (forall a . Ord a) is not the same as (forall a . Num a) Regards, Keean.

2 1

Re: Set Monad Problem...
by MR K P SCHUPKE 31 Mar '04

31 Mar '04

Okay, what is wrong with using a State Monad where the state is a Set. You can then define additional functions to insert etc. Regards, Keean.

1 0

RE: [Haskell-cafe] Adding Ord constraint to instance Monad Set?
by Simon Peyton-Jones 31 Mar '04

31 Mar '04

| > bindSet :: forall a b. (Ord a, Ord b) | > => T a -> (a -> T b) -> T b | | To translate the question from my problem to this one: | What would be if Set would be declared within Ord context, i.e. | data (Ord a) => Set a = ... | ? Now it would be safe to use Set as Monad because Sets could only | constructed from Ord types. No, the same problem arises. You could imagine that every Set contains its Ord methods. Then bind wouldn't need to pass them. But return :: Monad a => a -> m a The Set instance would have to be unitSet :: a -> Set a Where does the Ord dictionary come from? No, this won't work. Some of this stuff is discussed in a very old paper of mine http://research.microsoft.com/%7Esimonpj/Papers/classhask.ps.gz But I can't promise it covers this particular issue, and it predates functional dependencies. | "Constraints on datatype declarations are a misfeature of Haskell, and | have no useful effect." | | Is this the final conclusion? Yes, it is, I believe. Constraints on data type declarations are a mis-feature. I tried to get them removed, but there was some argument that they could be made useful (see John Hughes's paper "Restricted data types in Haskell", Haskell workshop 1999), and they stayed. Simon

2 1

Re: [Haskell-cafe] Adding Ord constraint to instance Monad Set?
by MR K P SCHUPKE 31 Mar '04

31 Mar '04

>This syntax would also have the advantage that you can apply different >contexts to different constructors. Er, you can already do that as I just pointed out: data (Ord a,Num b) => Either a b = Left a | Right b Note that to constrain the same type variable differently for different constructors would be a type error. In other words this: data Either a = Num a => Left a Ord a => Right a Is not valid, because (forall a . Num a) is not the same type as (forall a . Ord a). So infact the current way of writing it as data (Num a) => Either a = Left a | Right a Is better because it does not allow you to make that mistake. Regards, Keean.

2 1

RE: [Haskell-cafe] Adding Ord constraint to instance Monad Set?
by MR K P SCHUPKE 31 Mar '04

31 Mar '04

| "Constraints on datatype declarations are a misfeature of Haskell, and | have no useful effect." |=20 | Is this the final conclusion? >Yes, it is, I believe. Constraints on data type declarations are a >mis-feature. I tried to get them removed, but there was some argument >that they could be made useful Might I try and pursuade you that mis-feature is a bit strong. A data type declaration creates two things - the data type itself and the constructor function. If you consider the constrains in the data type declaration to apply only to the constructor then it all makes sense. functions do not infer constrains from enclosed functions, for example: fna :: Num a => a -> a fna a = -a fnb :: a -> a fnb a = fna a In this case fna has a type error, the function is declared without the required Num a constraint. This is the same for data constructors, consider: data Num a => MyList a = MyList [a] This means that the constuctor for mylist has the (Num a) constraint. Simple! This is not a misfeature - more a mis-understood feature. So, using: print $ MyList ['a','b','c'] -- fails: No instance for (Num Char) print $ MyList [1,2,3] -- is Okay. and unexpectedly a use of the constructor does not get the constraint: fnc :: a -> MyList a fnc a = MyList [a] -- fails: Could not deduce (Num a) from the context () But if you consider the constructor to be just like a normal function this is perfectly consistant. This should definitely not be removed, as there is no other way to apply a constaint to a constructor function. Regards, Keean.

3 2

RE: [Haskell-cafe] Adding Ord constraint to instance Monad Set?
by MR K P SCHUPKE 31 Mar '04

31 Mar '04

But that is already used for existential datatypes: data Test = forall a . Num a => Test a Maybe that lack of forall is enough to distinguish the two though. Your example would currently be written: data (Ord a,Num b) => Either a b = Left a | Right b I dont have any problem with this, just remember these are constraints on function arguments... It my superficially look like a class system, but in reality it is more like a constraint based programming language (for example Prolog) at the type level... Regards, Keean.

1 0

RE: [Haskell-cafe] Adding Ord constraint to instance Monad Set?
by Simon Peyton-Jones 31 Mar '04

31 Mar '04

Alex | Following the declaration of "instance Monad []" | in the prelude, and puzzling over the absence of | its equivalent from Data.Set, I naively typed: | | instance Monad Set where | m >>= k = concatSets (mapSet k m) | return x = unitSet x | fail s = emptySet | | concatSets sets = foldl union emptySet (setToList sets) | instance (Eq b,Ord b) => Ord (Set b) where | compare set1 set2 = compare (setToList set1) (setToList set2) | | and got the following error: | | Could not deduce (Ord b) from the context (Monad Set) | arising from use of `concatSets' at dbMeta3.hs:242 I'm sorry to say that you just can't make Set an instance of Monad. To make an instance of Monad for a type constructor T you must have a function bindT :: forall a b. T a -> (a -> T b) -> T b And there just *is* no such function for Set, because of the need for ordering. There's a less polymorphic function bindSet :: forall a b. (Ord a, Ord b) => T a -> (a -> T b) -> T b To see why this is no good, consider sequence :: Monad m => [m a] -> m [a] The code for sequence calls (>>=) a lot. You can't supply bindSet as the function to call because bindSet takes two Ord parameters at run-time, whereas ordinary bind does not. It's not just a quirk of the type system -- there is a real problem! Simon

3 2

[Haskell-cafe] RE: [Haskell] Programming language shootout (completing theHaskell entry)
by Simon Marlow 31 Mar '04

31 Mar '04

> When compiling via gcc, there's the __builtin_prefetch function: > > http://gcc.gnu.org/onlinedocs/gcc-3.3.3/gcc/Other-Builtins.html > (about 2/3rds of the way down the page) Thanks, I wasn't aware of that. > see also: > http://gcc.gnu.org/projects/prefetch.html > > I didn't read it very carefully, but it's not clear (on the > x86 cpus) if > there is a prefetch instruction that is common between the amd & intel > flavours, ie would a ghc binary with prefetch be portable between > P3/P4/Athlon. P3/P4 and Athlon have different prefetch instructions. However, Athlon64 supports the P3/P4 instructions. Cheers, Simon

1 0

Re: [Haskell-cafe] Context for type parameters of type constructors
by MR K P SCHUPKE 30 Mar '04

30 Mar '04

>I didn't get the point yet why the context for 'data' >is not sufficient for the 'instance' method definition. Not sure who's relpy you're replying to, but I thought my response was pretty clear (I would though)... The problem is that to define 'zero' the type of the 'zero' must unify with the vector type. If you define vector operations as (v a) then a is a polymorphic variable. However the definition of zero implies that a is an Integral .. these are not the same type: (forall a . a) is not (forall a . Integral a => a) and thats where the type error comes from. You have two choices, drop the definition of zero, or use multi-parameter type classes. You could get rid of zero and have: class VectorSpace v where set :: Num a => a -> v a add :: Num a => v a -> v a -> v a scale :: Num a => a -> v a -> v a Should do the trick! (zero becomes "set 0") Regards, Keean.

3 3