On 2 Apr 2008, at 16:20, Loup Vaillant wrote:
class AdditiveSemiMonoid a where
(+) :: a - a - a
Err, why *semi* monoid? Plain monoid would not be accurate?
I found an example where it is crucial that the monoid has a unit:
When given a monoid m, then one can also define an m-algebra, by
On Wed, 2 Apr 2008, Hans Aberg wrote:
Show could be implemented by writing out the function closures, but I
think the reason it is not there is that it would create overhead in
compiled code.
It would also not give referential transparent answers, because the same
function can be
On 3 Apr 2008, at 07:59, Henning Thielemann wrote:
But one should also be able to write (f+g)(x). - This does not
work in Haskell, because Num requires an instance of Eq and Show.
You could define these instances with undefined function
implementations anyway. But also in a more cleaner
On 3 Apr 2008, at 08:07, Henning Thielemann wrote:
Show could be implemented by writing out the function closures,
but I think the reason it is not there is that it would create
overhead in compiled code.
It would also not give referential transparent answers, because the
same function
On 2 Apr 2008, at 11:22, Henning Thielemann wrote:
It seems me it may come from an alteration of math conventions:
Normally (x) = x, and function application is written as f(x), except
for a few traditional names, like for example sin x. So if one
reasons that f(x) can be simplified to f x,
On Tue, 1 Apr 2008, Hans Aberg wrote:
On 1 Apr 2008, at 12:40, PR Stanley wrote:
Why can't we have function application implemented outwardly
(inside-out). So
f g x would be applied with
gx first followed by its return value passed to f instead of
putting g x in brackets.
It seems
Hans Aberg writes:
...
But one should also be able to write (f+g)(x). - This does not work in
Haskell, because Num requires an instance of Eq and Show.
So, declare them, even if they are vacuous. I did it several times, I am
still alive, so no need to say this does not work.
Jerzy
On 2 Apr 2008, at 13:51, [EMAIL PROTECTED] wrote:
But one should also be able to write (f+g)(x). - This does not
work in Haskell, because Num requires an instance of Eq and Show.
So, declare them, even if they are vacuous. I did it several times,
I am
still alive, so no need to say this
Hans Aberg comments my remark to his observation:
But one should also be able to write (f+g)(x). - This does not work in
Haskell, because Num requires an instance of Eq and Show.
So, declare them, even if they are vacuous. I did it several times, I am
still alive, so no need to say this
On 2 Apr 2008, at 14:27, [EMAIL PROTECTED] wrote:
That is possible, of course - I did that, too. But it means that
the syntax and semantics do not work together; an invitation to
pitfalls. So this ought to be avoided, except if there are no
other workarounds.
I am more tolerant.
The
On 2 Apr 2008, at 14:27, [EMAIL PROTECTED] wrote:
It would be better to write a new Prelude. :-)
Oh, yes, our common dream...
One may not need to write a wholly new Prelude, by something like:
module NewPrelude where
import Prelude hiding -- Num, (+).
class AdditiveSemiMonoid a where
2008/4/2, Hans Aberg [EMAIL PROTECTED]:
On 2 Apr 2008, at 14:27, [EMAIL PROTECTED]
wrote:
It would be better to write a new Prelude. :-)
Oh, yes, our common dream...
One may not need to write a wholly new Prelude, by something like:
module NewPrelude where
import Prelude hiding
On 2 Apr 2008, at 16:20, Loup Vaillant wrote:
class AdditiveSemiMonoid a where
(+) :: a - a - a
Err, why *semi* monoid? Plain monoid would not be accurate?
A monoid has a unit:
class (AdditiveSemiMonoid a) = AdditiveMonoid a where
o :: a
The semimonoid is also called semigroup, I
On Apr 2, 2008, at 10:27 , Hans Aberg wrote:
On 2 Apr 2008, at 16:20, Loup Vaillant wrote:
rant
While we're at it, what about adding even more classes, like group
or ring? Algebra in a whole class hierachy. :-)
Only ambition required :-).
On 2 Apr 2008, at 16:30, Brandon S. Allbery KF8NH wrote:
While we're at it, what about adding even more classes, like group
or ring? Algebra in a whole class hierachy. :-)
Only ambition required :-).
http://www.haskell.org/haskellwiki/Mathematical_prelude_discussion
--- go nuts.
There is
On Wed, 2 Apr 2008, Hans Aberg wrote:
But one should also be able to write (f+g)(x). - This does not work in
Haskell, because Num requires an instance of Eq and Show.
You could define these instances with undefined function implementations
anyway. But also in a more cleaner type hierarchy
PR Stanley wrote:
Why can't we have
function application implemented outwardly (inside-out).
No reason we can't.
We could.
We just don't.
People have spent some time thinking and experimenting and have decided
this way round is more convenient. It's certainly possible to disagree.
Jules
Paul Stanley writes:
Hi
If
f x = x
and
g y = y
then
f g x
returns an error because f takes only one argument. Why can't we have
function application implemented outwardly (inside-out)
etc.
Paul,
There were already some answers, but it seems that people did not react to
the statement
Hi
If
f x = x
and
g y = y
then
f g x
returns an error because f takes only one argument. Why can't we have
function application implemented outwardly (inside-out). So
f g x would be applied with
gx first followed by its return value passed to f instead of putting
g x in brackets.
Cheers,
On 01/04/2008, PR Stanley [EMAIL PROTECTED] wrote:
Hi
If
f x = x
and
g y = y
then
f g x
returns an error because f takes only one argument. Why can't we have
function application implemented outwardly (inside-out). So
f g x would be applied with
gx first followed by its return
PR Stanley wrote:
Hi
If
f x = x
and
g y = y
then
f g x
returns an error because f takes only one argument. Why can't we have
function application implemented outwardly (inside-out).
Why should it be so?
So
f g x would be applied with
gx first followed by its return value passed to f instead
2008/4/1, Jules Bean [EMAIL PROTECTED]:
PR Stanley wrote:
Why can't we have
function application implemented outwardly (inside-out).
No reason we can't.
We could.
We just don't.
People have spent some time thinking and experimenting and have decided
this way round is more
On 1 Apr 2008, at 12:40, PR Stanley wrote:
Why can't we have function application implemented outwardly
(inside-out). So
f g x would be applied with
gx first followed by its return value passed to f instead of
putting g x in brackets.
It seems me it may come from an alteration of math
Think about this:
map (+1) [1..10]
What should it do?
take (+1) and return a function which takes a list as its
argument and finally return a list.
How about:
f 1 2 3
Should that be f (1 (2 3)), or ((f 1) 2) 3?
The latter, of course, but that's not really what I'm
24 matches
Mail list logo
