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":
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.