(+), (&&) ... are different. Because they have classical tradition
to be applied as binary infix operations.
And gcd, min, max, lcm have not this "infix" tradition.
--
Sergey Mechveliani
[EMAIL PROTECTED]
"S.D.Mechveliani" wrote:
> Suggestion for standard library:
>
> to remove the names minimum(By), maximum(By)
> and to make min(By), max(By), gcd, lcm
> for the lists only.
> For example,
> min [x,y], min [x,y,x,u],
Keith Wansbrough wrote:
> > OTOH, if we were to redefine all the xxxBy functions that involve
> > comparison, I'd vote for ((<=) :: a->a->Bool) over (compare ::
> > a->a->Ordering) as the comparison function since (<=) is often easier to
> > create a quick definition for. I wouldn't consider suc
Dear All,
Please could somebody post a short, plain text summary of the discussion
in this thread? The recent exchanges have been long and involved, which
has made it impossible for me (and other busy onlookers too, I suspect)
to keep up. Without such a summary, I think that this thread may be
Please forward. We apologize for any duplication of this message
in your mailbox.
Best regards,
Nuno Barreiro
--
=
>From: Frank Atanassow <[EMAIL PROTECTED]>
>To: Jan Brosius <[EMAIL PROTECTED]>
>Cc: <[EMAIL PROTECTED]>
>Sent: Thursday, May 18, 2000 2:53 PM
>Subject: Re: more detailed explanation about forall in Haskell
> Jan Brosius writes:
> > I must put this in the good way;
> >
> > [forall x . alpha(
Dear all,
A reminder that the deadline for papers for the HOOTS workshop is coming
up, on June 22 2000. Only a month to go!
Alan.
--
Alan Jeffrey http://fpl.cs.depaul.edu/ajeffrey/
CTI, DePaul University, 243 S. Wabash Ave, Chicago 60604, USA
--
Peter Douglass wrote:
| [Lava] I'm interested to know the rationale behind
| removing the monads.
The reason we removed the monads was that circuits with
feedback (loops) in them became very tedious to define. One
had to use monadic fixpoint operators (or "softer" variants
on them), which were
Jerzy,
1. Block simulators, dataflow interfacing etc...
People mentiond FRAM, but somehow I missed (improbable
that nobody fired the *obvious* keyword here): HAWK!!!
See the Haskell Home page, you find all about.
This is exactly what I have been looking at. My be problem is how to
dynam
Koen Claessen wrote:
> But if you find that the Hawk way is interesting to do these
> kind of things, take a look at Lava as well. Lava has
> recently gotten a major rewrite (no monads left!), ...
I'm interested to know the rationale behind removing the monads. My
admittedly small experience wi
Jan Brosius writes:
> I must put this in the good way;
>
> [forall x . alpha(x)] => alpha(x) is True
Yes, by instantiation.
> If alpha(x) is TRUE then the following is true : alpha(x) => [forall x.
> alpha(x)]
No, alpha(x) only asserts that some element named x satisfies alpha. It does
no
> OTOH, if we were to redefine all the xxxBy functions that involve
> comparison, I'd vote for ((<=) :: a->a->Bool) over (compare ::
> a->a->Ordering) as the comparison function since (<=) is often easier to
> create a quick definition for. I wouldn't consider such a change until
> Haskell 2, tho
Koen Claessen wrote:
> I did not reply with *my* abvious answer: LAVA!! :-) This is
> because I thought the original question was about
> *continuous* systems, and Lava (and Hawk) are about
> discrete/digital systems.
>
> But if you find that the Hawk way is interesting to do these
> kind of thi
Mike Jones asked:
| Has anyone built any block simulators (for modeling
| continuous electronic systems, like OP Amps, RC
| networks, etc) in Haskell?
Johannes Waldmann added:
| I'm also interested in this. I am thinking of
| extending Paul Hudak's Haskore system to generate and
| handle
- Original Message -
From: Jan Brosius <[EMAIL PROTECTED]>
To: Carl R. Witty <[EMAIL PROTECTED]>
Sent: Thursday, May 18, 2000 12:06 PM
Subject: Re: Fw: more detailed explanation about forall in Haskell
> Thanks Carl for letting me see an ugly error that I made . SHAME on me.
>
> the eq
Sorry, if in some way I have upset you
Sincerely
Jan Brosius
>From: Frank Atanassow <[EMAIL PROTECTED]>
>To: Frank Atanassow <[EMAIL PROTECTED]>
>Sent: Wednesday, May 17, 2000 1:50 PM
>Subject: Fw: more detailed explanation about forall in Haskell
> Frank Atanassow writes:
> > Jan Brosius writ
>>>From: Frank Atanassow <[EMAIL PROTECTED]>
>To: Jan Brosius <[EMAIL PROTECTED]>
>Cc: <[EMAIL PROTECTED]>>
>Sent: Wednesday, May 17, 2000 1:35 PM
>Subject: Fw: more detailed explanation about forall in Haskell
> Jan Brosius writes:
> > > Why do some computer scientists have such problems with
Thanks for your comments.
They are to the point.
But the first email arose from the fact that someone else claimed that
the forall quantifier was used in the same way as in (say "classical")
logic.
I still claim that everything could be put in a classical logic framework,
which is then another
Johannes Waldmann :
> > > Has anyone built any block simulators (for modeling continuous electronic
> > > systems, like OP Amps, RC networks, etc) in Haskell?
>
> I'm also interested in this. I am thinking of extending
> Paul Hudak's Haskore system to generate and handle true audio data
> (inste
> > Has anyone built any block simulators (for modeling continuous electronic
> > systems, like OP Amps, RC networks, etc) in Haskell?
I'm also interested in this. I am thinking of extending
Paul Hudak's Haskore system to generate and handle true audio data
(instead of, or in addition to) MID
20 matches
Mail list logo
