...

not deeply understanding the use of Haskell extensions in the State source,

I'm assuming Control.Monad.State's source in which case -no- extensions are used for -State- (well, at least I don't see any quickly glancing). Extensions are used for the -MonadState class-.

The portable parts of Control.Monad.State (that are sufficient for most cases) should be in an extra module (maybe called Control.Monad.StateTypes). In addition further non-overloaded names for put, get, gets and modify would be needed (maybe putState, getState, etc.) There's no point to write your own "instance Monad ..." just because you want (or have) to be Haskell98 compliant. The previous "newtype Labeller a = Labeller (Int -> (Int, a))" (the result tuple is reversed within Control.Monad.State) would simply become (untested): newtype Labeller a = State Int a newLabel = do { n <- get; put (n + 1); return (Label n) } runLabeller l = execState l minBound Christian

On Friday, 2003-06-27, 12:55, CEST, Christian Maeder wrote:

[...]

The portable parts of Control.Monad.State (that are sufficient for most cases) should be in an extra module (maybe called Control.Monad.StateTypes). In addition further non-overloaded names for put, get, gets and modify would be needed (maybe putState, getState, etc.)

Hello, I fear, this would complicate the module structure too much. And it will become unnecessary because some time (in the near future?) multi-parameter classes with functional dependencies will be a standardized feature which is supported by all major Haskell implementations. I hope, at least. ;-)

[...]

Wolfgang

On Thursday, 2003-06-26, 23:57, CEST, Derek Elkins wrote:

[...]

...

not deeply understanding the use of Haskell extensions in the State source,

I'm assuming Control.Monad.State's source in which case -no- extensions are used for -State- (well, at least I don't see any quickly glancing). Extensions are used for the -MonadState class-. For the MonadState class they are pretty much necessary. Multiparameter type classes are necessary because the state type depends on the monad (get would have type forall s.Monad m => m -> s otherwise which is rather meaningless), the function dependencies tell the type checker that the state type is completely determined by the monad type.

Hello, why not swap the state and the monad parameter of StateT? The definition would become something like the following: newtype StateT m s a = StateT (s -> m (a,s)) With this we could create a MonadState class which doesn't use type system extensions. It could be defined like this: class MonadState m where get :: m s s put :: s -> m s () Note that m now has kind * -> * -> *. Note also that this restricts the MonadState class because only state transformers which can work with every state type are now possible as instances. But, at least, State and our modified StateT can be instantiated without problem. The problem arises when we try to make a MonadTrans instance for our new StateT because MonadTrans needs a type of kind * -> * -> * whoose first argument is a monad. But we can create a different MonadTrans class based on the kind of functional dependency usage we just dropped for MonadState. We just write: class MonadTrans (Monad m, Monad tm) => m tm | tm -> m where lift :: m a -> tm a Instead of writing instance MonadTrans T where ... we would now write instance Monad m => MonadTrans m (T m) where ... and for our new StateT type we would write instance Monad m => MonadTrans m (StateT m s) where ... The new MonadTrans class would be more powerful. This would have the nice effect that we don't need MonadIO anymore. Instead of writing MonadIO m we could just use MonadTrans IO m Changing MonadTrans this way would help me with my parser module.¹ I have a type Parser which needs three parameters, a "base monad", a token type and an output type. The base monad parameter has the same purpose as the monad parameter in ReaderT, WriterT, StateT etc. The lift function makes sense for my parser type, so I want a MonadTrans instance. This would restrict me to the parameter order token - base monad - output which is rather unfortunate for me. The reason is that there are parser functions which fulfill the arrow axioms. The arrow type is a parser applied to a specific base monad. So I want to write something like instance Monad baseMonad => Arrow (Parser baseMonad) where ... which implies that the base monad must be the first parameter. This brings me to another point. One year ago we had a discussion on The Haskell Mailing List concerning arrows. (The subject of the mails was just "arrows".) The point was that it seemed strange to me that first and second are included in the basic arrow class Arrow while left and right have their extra class ArrowChoice. Not only that it seemed strange to me but it made it impossible to make Parser baseMonad an instance of Arrow. Parser baseMonad has nice implementations of pure and (>>>) but none of first or second. Currently, I use my own Arrow module which provides an arrow class, that doesn't include first and second. I'm really not happy with using a replacement for a module from the hierarchical libraries. Is there any chance of changing the class structure of Control.Arrow?

[...]

Wolfgang ¹ The parser module is part of Seaweed. It's the module Seaweed.Core.Parsing. The source code of Seaweed can be accessed via this URI: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/seaweed/code/ There is also the module Seaweed.Core.Parsing.Utilities which provides several useful things implemented on top of the core parsing module.

Ashley Yakeley wrote:

Wolfgang Jeltsch wrote:

...

This brings me to another point. One year ago we had a discussion on The Haskell Mailing List concerning arrows. (The subject of the mails was just "arrows".) The point was that it seemed strange to me that first and second are included in the basic arrow class Arrow while left and right have their extra class ArrowChoice. Not only that it seemed strange to me but it made impossible to make Parser baseMonad an instance of Arrow. Parser baseMonad has nice implementations of pure and (>>>) but none of first or second.

I agree. My own Arrow module hierarchy looks more or less like this:

class Compositor comp where [...] class (Compositor arrow) => Arrow arrow where [...] class (Arrow arrow) => ProductArrow arrow where [...] class (Arrow arrow) => CoproductArrow arrow where [...] class (ProductArrow arrow,CoproductArrow arrow) => FullArrow arrow instance (ProductArrow arrow,CoproductArrow arrow) => FullArrow arrow class (Arrow arrow) => ArrowFix arrow where [...] class (FullArrow arrow) => ApplyArrow arrow where [...]

On that topic, see below for what mine looks like (from HXML, http://www.flightlab.com/~joe/hxml/ >). I started off with Hughes' conventions, but for some reason could never remember the difference between &&& and ***, or between ||| and +++. I found &&&, >&<, |||, >|< to have better mnemonic value. This also frees up +++ for ArrowPlus, which -- in HXML applications -- is frequently used and should thus be easy to type. When using the ArrowChoice operators, I kept tripping over all the 'Either' coproduct types, so added some syntactic sugar (borrowed from HaXML): data Choice a = a :> a class (Arrow a) => ArrowChoice a where [ ... ] ( ?>) :: (b -> Bool) -> Choice (a b c) -> a b c (>?>) :: a b Bool -> Choice (a b c) -> a b c I found "p ?> f :> g" much more pleasant to use. (I also like the idea of splitting the product operators out of the base Arrow class -- will consider doing that in my library). -- infixr 5 +++ infixr 3 >&<, &&& infixr 2 >|<, |||, ?>, >?>, :> infixl 1 >>> class Arrow a where arr :: (b -> c) -> a b c (>>>) :: a b c -> a c d -> a b d apfst :: a b c -> a (b,x) (c,x) apsnd :: a b c -> a (x,b) (x,c) (>&<) :: a b c -> a d e -> a (b,d) (c,e) (&&&) :: a b c -> a b d -> a b (c,d) liftA2 :: (b -> c -> d) -> a e b -> a e c -> a e d aConst :: c -> a b c idArrow :: a b b -- Minimal implementation: arr, >>>, apfst or >&< data Choice a = a :> a class (Arrow a) => ArrowChoice a where apl :: a b c -> a (Either b d) (Either c d) apr :: a b c -> a (Either d b) (Either d c) (>|<) :: a b c -> a d e -> a (Either b d) (Either c e) (|||) :: a b c -> a d c -> a (Either b d) c ( ?>) :: (b -> Bool) -> Choice (a b c) -> a b c (>?>) :: a b Bool -> Choice (a b c) -> a b c -- Minimal implementation: >|< or apl class (Arrow a) => ArrowApply a where app :: a (a b c,b) c class (Arrow a) => ArrowZero a where aZero :: a b c aMaybe :: a (Maybe c) c aGuard :: (b -> Bool) -> a b b class (Arrow a) => ArrowPlus a where (+++) :: a b c -> a b c -> a b c --Joe English jenglish@flightlab.com

In article <20030630150455.GA8927@soi.city.ac.uk>, Ross Paterson wrote:

The point about symmetry is a fair one, but unfortunately the Haskell class system imposes a cost on fine-grained class hierarchies,

It does? -- Ashley Yakeley, Seattle WA

On Thu, Jul 10, 2003 at 02:33:25PM +0100, Ross Paterson wrote:

Subclasses in Haskell cover a range of relationships, including this sense where things in the subclass automatically belong to the superclass. Other examples include Eq => Ord and Functor vs Monad. In such cases it would be handy if the subclass could define defaults for the superclass methods (e.g. Ord defining (==)), so that the superclass instance could be optional.

I agree, but this needs to be carefully thought out. For instance, remember to consider the case that there is more than one default instance for a given method of a superclass. I am reminded of multiple inheritance considerations. (These difficulties came up before when I was thinking about the numeric heirarchy, and was the reason I proposed a heirarchy which was much less fine-grained than, e.g., in Mechvelliani's proposal.) Peace, Dylan

On Thursday, 2003-07-10, 15:33, Ross Paterson wrote:

[...]

Subclasses in Haskell cover a range of relationships, including this sense where things in the subclass automatically belong to the superclass. Other examples include Eq => Ord and Functor vs Monad.

By the way, I strongly vote for Functor being a superclass of Monad in Haskell 2.

[...]

Wolfgang

I'm glad to hear there isn't a _serious_ cost (i.e. performance penalty) for fine-grained hierarchies.

One cost which doesn't seem to have been mentioned is the programmer cost. With the current Haskell Prelude, a matrix operation (say) might have type: invert :: Num a => Matrix a -> Matrix a but, if we had one operation per class, the type might be: invert :: (Add a, Subtract a, FromInteger a, Eq a, Multiply a) => Matrix a -> Matrix a More flexible but quite unwieldy. One way to overcome part of this problem would be to generalize the idea of 'type synonyms' to allow 'context synonyms'. For example, we have type synonyms like: type Point = (Int,Int) we could have 'context synonyms' like: class Num a => (Add a, Subtract a, FromInteger a, Eq a, Multiply a, ...) Adding context synonyms would make it possible to write types concisely when using fine-grained class hierarchies and would also be useful with extensions like Hugs' T-REX or implicit parameters. Adding context synonyms would not help with type error messages though. When using TREX to encode an abstract syntax tree for the C language, I once got an error message that was over two pages long (i.e., about 4000 characters long). The error message amounted to saying that one list of fields didn't match another list of fields but with two pages of field names to look at, it was impossible to say what the differences between the types were. Things would not be that bad with the example types above but they would certainly be harder than the current error messages. -- Alastair Reid

Alastair Reid writes:

...

I'm glad to hear there isn't a _serious_ cost (i.e. performance penalty) for fine-grained hierarchies.

One cost which doesn't seem to have been mentioned is the programmer cost.

With the current Haskell Prelude, a matrix operation (say) might have type:

invert :: Num a => Matrix a -> Matrix a

but, if we had one operation per class, the type might be:

invert :: (Add a, Subtract a, FromInteger a, Eq a, Multiply a) => Matrix a -> Matrix a

More flexible but quite unwieldy.

IIRC, Clean essentially has this. Though it's more like invert :: (+ a, - a, FromInteger a, = a, * a) => Matrix a -> Matrix a (I may be wrong about the syntax and the specifics :-) - Hari -- Raja R Harinath ------------------------------ harinath@cs.umn.edu

Dnia pon 14. lipca 2003 10:18, Graham Klyne napisał:

I must be missing something... isn't the effect achieved by: class (Add a, Subtract a, FromInteger a, Eq a, Multiply a, ...) => Num a ?

It doesn't provide instances of Num for anything which is already an instance of the other classes. And in Haskell 98 they must be defined separately for each type, instance (...) => Num a doesn't work. -- __("< Marcin Kowalczyk \__/ qrczak@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/

On Tue, Jul 15, 2003 at 01:07:12AM -0700, Ashley Yakeley wrote:

In article <200307141536.39157.qrczak@knm.org.pl>, Marcin 'Qrczak' Kowalczyk wrote:

...

It doesn't provide instances of Num for anything which is already an instance of the other classes. And in Haskell 98 they must be defined separately for each type, instance (...) => Num a doesn't work.

It works in extended Haskell however, so I suspect it lays to rest the question of needing some other language extension.

I disagree! This method (putting each function in its own class) does not address two related points: a) Being able to declare default values for a method declared in a superclass; b) Being able to refine a type heirarchy without the users noticing (and without explosion of the number of instance declarations required). Peace, Dylan