Why isn’t (>>>) a method?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Why isn’t (>>>) a method?

Wolfgang Jeltsch-2
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
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Why isn’t (>>>) a method?

Henrik Nilsson
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
[hidden email]

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.

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Why isn’t (>>>) a method?

Isaac Dupree
In reply to this post by Wolfgang Jeltsch-2
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
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Why isn’t (>>>) a method?

David Menendez-2
In reply to this post by Wolfgang Jeltsch-2
On Wed, Nov 26, 2008 at 9:38 AM, Wolfgang Jeltsch
<[hidden email]> wrote:
> 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 <[hidden email]>
<http://www.eyrie.org/~zednenem/>
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Why isn?t (>>>) a method?

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.
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Why isn?t (>>>) a method?

David Menendez-2
On Wed, Nov 26, 2008 at 4:38 PM, Ross Paterson <[hidden email]> wrote:

> 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 <[hidden email]>
<http://www.eyrie.org/~zednenem/>
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries