Ashley Yakeley wrote:
Jon Fairbairn wrote:
I think "joining up the classes" is a good idea,
Definitely -- as is slicing them into finer layers (of which
this is also an example).
I have added a ticket for "joined-up classes":
http://hackage.haskell.org/trac/haskell-prime/ticket/113
So, with this arrangement, quite a lot of library functionality is
potentially affected (good!), especially if Traversable is also kicking
around, allowing us
crush :: (Monoid t, Traversable f) => (s -> t) -> f s -> t
(1) Which library functions should just be binned?
(2) Which library functions should be retained but generalised (eg,
working for Applicative rather than Monad, or any Traversable f rather
than just [])? In particular, what happens to mapM?
Of course, there's a danger that such moves will raise the level of
sophistication required to get to grips with the library (revisiting the
map versus fmap debate).
I'm very much in favour of "joined-up classes", but it does leave us
with quite a lot to work through. How to proceed? What are the guidelines?
Meanwhile, I don't suppose you'll let me have the 'idiom bracket'
notation, [| .. |] or some such, with
[| f a1 .. an |]
expanding to the old Welsh program (ap is the Welsh patronymic prefix)
return f `ap` a1 `ap` .. `ap` an
Thought I might be pushing my luck. I know, it's frivolous extra syntax
serving only to improve the signal-to-noise ratio of code by a constant
factor, and that ain't enough.
All the best
Conor
This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.
_______________________________________________
Haskell-prime mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-prime
