| A row has a formula and a weight. | | > data Formula f => Row a = Row (f a, Weight) | | Line 14 is the definition of Row. Can anyone explain the | proper use of a context in a data definition? All the type variables in the constructor arguments must be introduced as type constructor args. Thus, for example: data Formula f => Row a f = Row (f a, Weight) woudl be ok. But I bet you wanted to say "f a is a formula, that has exactly the operations of class Formula available". You probably don't want the 'f' to appear in the type (Row a f). In that case you need an exisitential type (not Haskell 98), which GHC and Hugs support thus: data Row a = forall f. Formula f => Row (f a, Weight) The existential is written 'forall' because the type of the Row constructor really is Row :: forall a f. Formula f => (f a, Weight) -> Row a Now you can pattern-match thus: f :: Row a -> Environment a -> Bool f (Row (x,w)) = eval x env A context on the LHS of a data type declaration is (in my opinion) one of Haskell's few blunders. It makes the constructor into an overloaded function, thus: Row :: (Formula f) => (f a, Weight) -> Row a That forces (Formula f) to hold at the call site of Row, but when you pattern match it isn't. So it simply makes fewer programs typecheck without increasing expressiveness. Indeed, as you found, it's positively misleading. Simon
In that case you need an existential type (not Haskell 98), which GHC and Hugs support thus:
data Row a = forall f. Formula f => Row (f a, Weight)
And incidentally, nhc98 also supports this particular extension with this syntax. (Hbc supports it too, but with a slightly different syntax.) Regards, Malcolm
On Thu, 5 Apr 2001, Malcolm Wallace wrote:
And incidentally, nhc98 also supports this particular extension with this syntax. (Hbc supports it too, but with a slightly different syntax.)
A propos language extensions. I have a case where multiparameter classes with functional dependencies are essential. I'm developing a unified collection interface (this is about a fifth try, but it finally seems to look well). It would be great if that extension was standard some day. It's also very helpful to have arbitrary types in instance contexts, not only type variables (it's not the first time I need it). Unfortunately it implies -fallow-undecidable-instances in ghc. I assume that the fact that it's undecidable makes it a poor candidate for general acceptance. So if some great brain found how to extend the decidable area to cover some richer instance contexts... A third extension which is ocasionally useful is not present in any Haskell implementation. I would like to say instance (forall a. Seq (s a) a) => Foo (Bar s) It would allow to e.g. wrap my collections in Edison's interfaces, not only vice versa. -- Marcin 'Qrczak' Kowalczyk
On Thu, Apr 05, 2001 at 01:18:48PM +0200, Marcin 'Qrczak' Kowalczyk wrote:
... I'm developing a unified collection interface (this is about a fifth try, but it finally seems to look well). ...
Is it ready for public consumption? Best, Dylan Thurston
Thu, 5 Apr 2001 09:59:30 -0400, Dylan Thurston <dpt@math.harvard.edu> pisze:
... I'm developing a unified collection interface (this is about a fifth try, but it finally seems to look well). ...
Is it ready for public consumption?
I will show something in a few days (incomplete). -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK
Thu, 5 Apr 2001 13:18:48 +0200 (CEST), Marcin 'Qrczak' Kowalczyk <qrczak@knm.org.pl> pisze:
I'm developing a unified collection interface
I've put the current state at <http://qrczak.ids.net.pl/data.tar.gz>. Not complete and lacks documentation, but you may want to look at it. Requires ghc-5.00, could be ported to Hugs. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK
participants (5)
-
Dylan Thurston -
Malcolm Wallace -
Marcin 'Qrczak' Kowalczyk -
qrczak＠knm.org.pl
-
Simon Peyton-Jones