ANNOUNCE: yap-0.0 - yet another prelude

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

ANNOUNCE: yap-0.0 - yet another prelude

Ross Paterson-2
Yet another restructuring of the Prelude numeric classes on algebraic lines, proposed for a revision of the Haskell Prelude:

http://hackage.haskell.org/package/yap-0.0

It is less ambitious and more simplistic than other algebraic class hierarchies, but it aims to preserve backward compatibility for clients of the existing classes, and avoids multiple parameter type classes.  Of course defaulting is affected (this would be fixed if this proposal became part of the language) and definitions of instances will be different (but this is where the existing hierarchy is most problematic).  The core of the package is the new class hierarchy, but it also has some example instances, including for the existing types Complex and Ratio.  It is simplistic, but enough to allow fields like Ratio (Polynomial (Ratio (Complex Integer))).
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: yap-0.0 - yet another prelude

Henning Thielemann

On Wed, 10 Aug 2011, Paterson, Ross wrote:

> Yet another restructuring of the Prelude numeric classes on algebraic lines, proposed for a revision of the Haskell Prelude:
>
> http://hackage.haskell.org/package/yap-0.0

A nice lightweight design, both in terms of the use of type extensions and
import dependencies, that should people encourage to use it, when they are
afraid of changing to a more radical approach like numeric-prelude. I
would have prefered the name AdditiveGroup to AbelianGroup, since with '+'
and '-' and '0' I associate more than just the laws of an Abelian group.
The multiplicative group of rational numbers is abelian, too.

  I also like the Quantity datatype. It can be used with any framework for
type-encoded physical units. I have for instance a Haskell98 approach,
that could be sepearated from numeric-prelude:
   http://hackage.haskell.org/packages/archive/numeric-prelude/0.2.2/doc/html/Algebra-DimensionTerm.html
  In this approach I encode composed units using type constructors like Mul
and Div and the user is responsible for showing that (Mul a b) is
equivalent to (Mul b a). Sure, its cumbersome, but Haskell 98 and I hope
you do not need those proofs very often.

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

Re: ANNOUNCE: yap-0.0 - yet another prelude

wren ng thornton
In reply to this post by Ross Paterson-2
On 8/10/11 9:53 AM, Paterson, Ross wrote:
> Yet another restructuring of the Prelude numeric classes on algebraic lines, proposed for a revision of the Haskell Prelude:
>
> http://hackage.haskell.org/package/yap-0.0

Very nice in its simplicity, but it suffers from the same problem as all
the other attempts I've seen. Namely it ignores the importance of
semirings and runs headlong towards fields and beyond. The {(-), abs,
signum, negate} methods really must be broken out from (+).

--
Live well,
~wren

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

RE: ANNOUNCE: yap-0.0 - yet another prelude

Ross Paterson-2
wren ng thornton [[hidden email]] writes:
> On 8/10/11 9:53 AM, Paterson, Ross wrote:
> > Yet another restructuring of the Prelude numeric classes on algebraic lines, proposed for a revision of the Haskell Prelude:
> >
> > http://hackage.haskell.org/package/yap-0.0
>
> Very nice in its simplicity, but it suffers from the same problem as all
> the other attempts I've seen. Namely it ignores the importance of
> semirings and runs headlong towards fields and beyond. The {(-), abs,
> signum, negate} methods really must be broken out from (+).

abs and signum are already split off, but it could be further split, with
Monoid and Semiring subclasses of AbelianGroup and Ring, and that
would fit nicely with a Natural type.  I wasn't sure it was worth it
(having + operate on lists might be confusing for beginners).
But this scheme doesn't preclude doing that later.
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

RE: ANNOUNCE: yap-0.0 - yet another prelude

Henning Thielemann

On Fri, 12 Aug 2011, Paterson, Ross wrote:

> wren ng thornton [[hidden email]] writes:
>> On 8/10/11 9:53 AM, Paterson, Ross wrote:
>>> Yet another restructuring of the Prelude numeric classes on algebraic lines, proposed for a revision of the Haskell Prelude:
>>>
>>> http://hackage.haskell.org/package/yap-0.0
>>
>> Very nice in its simplicity, but it suffers from the same problem as all
>> the other attempts I've seen. Namely it ignores the importance of
>> semirings and runs headlong towards fields and beyond. The {(-), abs,
>> signum, negate} methods really must be broken out from (+).
>
> abs and signum are already split off, but it could be further split, with
> Monoid and Semiring subclasses of AbelianGroup and Ring, and that
> would fit nicely with a Natural type.  I wasn't sure it was worth it
> (having + operate on lists might be confusing for beginners).

Having a (+) is possible for both Additive Group or more fine-grained
classes, isn't it? There is still the question, whether (+) lists shortens
like zipWith (+) or expands to the longer list. Or do you even mean to
define (+) as being (++) on lists? (Which would be also non-commutative,
that is, non-Abelian.)

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

Re: ANNOUNCE: yap-0.0 - yet another prelude

Sebastian Fischer-2
In reply to this post by Ross Paterson-2
>> it ignores the importance of
>> semirings and runs headlong towards fields and beyond.
>
> abs and signum are already split off, but it could be further split, with
> Monoid and Semiring subclasses of AbelianGroup and Ring, and that
> would fit nicely with a Natural type.  I wasn't sure it was worth it

+1 for adding Monoid and Semiring earlier rather than later which
would allow me to drop my own definitions for semirings in my
libraries for regular expression matching and parallel programming.

Sebastian

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

RE: ANNOUNCE: yap-0.0 - yet another prelude

Ross Paterson-2
Sebastian Fischer writes:
> +1 for adding Monoid and Semiring earlier rather than later which
> would allow me to drop my own definitions for semirings in my
> libraries for regular expression matching and parallel programming.

I see your versions of + and * are infixr rather than infixl.
Is that important?
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: yap-0.0 - yet another prelude

Sebastian Fischer-2
On Mon, Aug 15, 2011 at 7:12 AM, Paterson, Ross <[hidden email]> wrote:
Sebastian Fischer writes:
> +1 for adding Monoid and Semiring earlier rather than later which
> would allow me to drop my own definitions for semirings in my
> libraries for regular expression matching and parallel programming.

I see your versions of + and * are infixr rather than infixl.
Is that important? 

I copied fixities from the Prelude [1] for + and * but don't know why they are infixl there.

I think, I even prefer right associative operators. For example, for the free semiring "bag of lists", + for bag union resembles ++ which is right associative.

Best regards,
Sebastian


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

Re: ANNOUNCE: yap-0.0 - yet another prelude

Sebastian Fischer-2
I see your versions of + and * are infixr rather than infixl.
Is that important? 

I copied fixities from the Prelude [1] for + and * but don't know why they are infixl there.

Sorry, I just saw that I confused infixl and infixr in your question. In fact, in my two Semiring modules I use different fixities. infixr in the regexp library and infixl (copied from Prelude) in the (not yet published) library for parallel programming. So apparently, I don't care very much ;)

Are there good arguments in favor of or against either choice?

Best regards,
Sebastian

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

Re: ANNOUNCE: yap-0.0 - yet another prelude

Wolfram Kahl
On Mon, Aug 15, 2011 at 10:00:03AM +0900, Sebastian Fischer wrote:

> >
> > I see your versions of + and * are infixr rather than infixl.
> >> Is that important?
> >
> >
> > I copied fixities from the Prelude [1] for + and * but don't know why they
> > are infixl there.
> >
>
> Sorry, I just saw that I confused infixl and infixr in your question. In
> fact, in my two Semiring modules I use different fixities. infixr in the
> regexp library and infixl (copied from Prelude) in the (not yet published)
> library for parallel programming. So apparently, I don't care very much ;)
>
> Are there good arguments in favor of or against either choice?

In the presence of - at the same precedence as + you want both to be infixl,
to get:

  a + b - c + d - e - f  =  ((((a + b) - c) + d) - e) - f

The same for * with /.


Wolfram

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

RE: ANNOUNCE: yap-0.0 - yet another prelude

Ross Paterson-2
Wolfram Kahl writes:

> On Mon, Aug 15, 2011 at 10:00:03AM +0900, Sebastian Fischer wrote:
> >> I see your versions of + and * are infixr rather than infixl.
> >> Is that important?
> >
> > I copied fixities from the Prelude [1] for + and * but don't know why they
> > are infixl there.
>
> > Sorry, I just saw that I confused infixl and infixr in your question. In
> > fact, in my two Semiring modules I use different fixities. infixr in the
> > regexp library and infixl (copied from Prelude) in the (not yet published)
> > library for parallel programming. So apparently, I don't care very much ;)
> >
> > Are there good arguments in favor of or against either choice?
>
> In the presence of - at the same precedence as + you want both to be infixl,
> to get:
>
>   a + b - c + d - e - f  =  ((((a + b) - c) + d) - e) - f
>
> The same for * with /.

Yes: they need to be left associative for backwards compatibility, and
it's an intuitive choice anyway.
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries