ANNOUNCE: yap-0.0 - yet another prelude
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))).
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:
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/A... 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.
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:
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
wren ng thornton [wren@freegeek.org] 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:
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.
On Fri, 12 Aug 2011, Paterson, Ross wrote:
wren ng thornton [wren@freegeek.org] 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:
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.)
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
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?
On Mon, Aug 15, 2011 at 7:12 AM, Paterson, Ross
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 [1] http://www.haskell.org/onlinereport/standard-prelude.html
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
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
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.
participants (5)
-
Henning Thielemann -
Paterson, Ross -
Sebastian Fischer -
Wolfram Kahl -
wren ng thornton