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, b
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 can
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 type
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 implemente
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 li
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
On Apr 2, 2008, at 10:27 , Hans Aberg wrote:
On 2 Apr 2008, at 16:20, Loup Vaillant 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_pre
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,
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
>
> impor
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
(+
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 pr
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 do
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 d
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 Karczm
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, then
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.
>
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
drivi
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 conve
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 roun
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 th
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
_
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 b
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
23 matches
Mail list logo
