Hello, I wonder why (>>>) is an ordinary function instead of a method with a default implementation based on (.). The latter would make life easier in two ways. First, it would be easier to write code which works with the old Arrow class and the new Category/Arrow solution (fewer CPP stuff). Second, I often find it easier to “think forwards” and use (>>>) instead of “thinking backwards” and using (.). So it would be nicer for me to use (>>>) in a method implementation instead of (.). Best wishes, Wolfgang
Hi all, I just want to support Wolfgang here. These changes (the new Category/Arrow solution) passed me by completely (too many other things to do). But I can't really see any strong reason for breaking backwards compatibility here by not sticking with (>>>) as a method? In fact, given that Category interferes with the standard prelude, I wonder if it was considered making (<<<) and (>>>) and "identity" methods of Category, leaving (.) and "id" alone? Such a design would have been beneficial for a library like Yampa, would have minimized backwards compatibility issues, and would have simplified life for end users (saves them from hiding the prelude "id" and (.). Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham nhn@cs.nott.ac.uk 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.
Wolfgang Jeltsch wrote:
Hello,
I wonder why (>>>) is an ordinary function instead of a method with a default implementation based on (.). The latter would make life easier in two ways.
But if you don't add some "instance Category...where (.)=...; id=...", then there are still problems! so compatibility is still an issue. and I have to say that your suggestion twists my mind a little bit. after all, Category is the super-class now. -Isaac
On Wed, Nov 26, 2008 at 9:38 AM, Wolfgang Jeltsch
I wonder why (>>>) is an ordinary function instead of a method with a default implementation based on (.).
It's easier to explain and provides fewer chances for mistakes. It's
the same reason Arrow no longer has both "arr" and "pure".
I'm not sure why they chose the name (.) for Category, rather than
(>>>) or (<<<).
I also think trying to shoe-horn a new, incompatible definition for
Arrow into a base-3.0.* release was a mistake. The whole point of
having a versioning policy is lost if you don't follow it. Given how
isolated Arrow is in the standard libraries, they could have just
created a new class and deprecated the old one without causing much
fuss.
--
Dave Menendez
On Wed, Nov 26, 2008 at 04:02:36PM -0500, David Menendez wrote:
I also think trying to shoe-horn a new, incompatible definition for Arrow into a base-3.0.* release was a mistake. The whole point of having a versioning policy is lost if you don't follow it. Given how isolated Arrow is in the standard libraries, they could have just created a new class and deprecated the old one without causing much fuss.
It is isolated in base, but it's also wired into GHC. The whole point of base-compat is to present a different view of the same entities, so that packages using the base-3 interface and those using the base-4 interface can be combined. There was no way that could work with a changed Arrow class.
On Wed, Nov 26, 2008 at 4:38 PM, Ross Paterson
On Wed, Nov 26, 2008 at 04:02:36PM -0500, David Menendez wrote:
I also think trying to shoe-horn a new, incompatible definition for Arrow into a base-3.0.* release was a mistake. The whole point of having a versioning policy is lost if you don't follow it. Given how isolated Arrow is in the standard libraries, they could have just created a new class and deprecated the old one without causing much fuss.
It is isolated in base, but it's also wired into GHC. The whole point of base-compat is to present a different view of the same entities, so that packages using the base-3 interface and those using the base-4 interface can be combined. There was no way that could work with a changed Arrow class.
But now base-3 isn't compatible with *itself*.
I see no reason why GHC couldn't use a mechanism like rebindable
syntax to support two Arrow classes. I'm free to define my own version
of Monad and use the do-synax with it. Besides, the arrow syntax
already requires a language extension; we could just provide a
different pragma for neo-Arrows. The old and new Arrow classes could
coexist perfectly fine.
Of course, Arrow libraries would end up needing a bunch of boilerplate
to provide instances for both classes. Whether that's preferable to
conditional compilation may be a matter of taste.
--
Dave Menendez
participants (5)
-
David Menendez -
Henrik Nilsson -
Isaac Dupree -
Ross Paterson -
Wolfgang Jeltsch