In article <[EMAIL PROTECTED]>,
Wolfgang Jeltsch <[EMAIL PROTECTED]> wrote:
> This brings me to another point. One year ago we had a discussion on The
> Haskell Mailing List concerning arrows. (The subject of the mails was just
> "arrows".) The point was that it seemed strange to me that first
Ashley Yakeley wrote:
> Wolfgang Jeltsch wrote:
>
> > This brings me to another point. One year ago we had a discussion on The
> > Haskell Mailing List concerning arrows. (The subject of the mails was just
> > "arrows".) The point was that it seemed strange to me that first and second
> > are incl
et by type checking pre-processed code.
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Joe
| English
| Sent: 28 June 2003 17:01
| To: [EMAIL PROTECTED]
| Subject: Re: Arrow Classes
|
|
| Ashley Yakeley wrote:
| > Wolfgang Jeltsch wrote:
| >
On Fri, Jun 27, 2003 at 07:27:36PM +0200, Wolfgang Jeltsch wrote:
> This brings me to another point. One year ago we had a discussion on The
> Haskell Mailing List concerning arrows. (The subject of the mails was just
> "arrows".) The point was that it seemed strange to me that first and second
In article <[EMAIL PROTECTED]>,
Ross Paterson <[EMAIL PROTECTED]> wrote:
> The point about symmetry is a fair one, but unfortunately the Haskell class
> system imposes a cost on fine-grained class hierarchies,
It does?
--
Ashley Yakeley, Seattle WA
___
On Thu, Jul 10, 2003 at 02:00:37AM -0700, Ashley Yakeley wrote:
> In article <[EMAIL PROTECTED]>,
> Ross Paterson <[EMAIL PROTECTED]> wrote:
>
> > The point about symmetry is a fair one, but unfortunately the Haskell class
> > system imposes a cost on fine-grained class hierarchies,
>
> It does
On Thursday, 2003-07-10, 15:33, Ross Paterson wrote:
> [...]
> There are more instances and methods for people to define, even if some of
> them imply others.
>
> As it happens, I would like yet another intermediate class:
>
> class BiFunctor a where
> bimap :: (b' -> b) -> (c
On Thursday, 2003-07-10, 15:33, Ross Paterson wrote:
> [...]
> Subclasses in Haskell cover a range of relationships, including this sense
> where things in the subclass automatically belong to the superclass. Other
> examples include Eq => Ord and Functor vs Monad.
By the way, I strongly vote for
In article <[EMAIL PROTECTED]>,
Wolfgang Jeltsch <[EMAIL PROTECTED]> wrote:
> By the way, I strongly vote for Functor being a superclass of Monad in
> Haskell 2.
I recently created my own Monad class in HBase instead of using the
Prelude one. The hierarchy looks something like this:
class H
In article <[EMAIL PROTECTED]>,
Ross Paterson <[EMAIL PROTECTED]> wrote:
> As it happens, I would like yet another intermediate class:
>
> class BiFunctor a where
> bimap :: (b' -> b) -> (c -> c') -> a b c -> a b' c'
This can be decomposed into:
fmap :: (c -> c') -> a b c
> I'm glad to hear there isn't a _serious_ cost (i.e. performance penalty)
> for fine-grained hierarchies.
One cost which doesn't seem to have been mentioned is the programmer cost.
With the current Haskell Prelude, a matrix operation (say) might have type:
invert :: Num a => Matrix a -> Ma
In article <[EMAIL PROTECTED]>,
Alastair Reid <[EMAIL PROTECTED]> wrote:
> One way to overcome part of this problem would be to generalize the idea of
> 'type synonyms' to allow 'context synonyms'. For example, we have type
> synonyms like:
>
> type Point = (Int,Int)
>
> we could have 'con
Alastair Reid <[EMAIL PROTECTED]> writes:
>> I'm glad to hear there isn't a _serious_ cost (i.e. performance penalty)
>> for fine-grained hierarchies.
>
> One cost which doesn't seem to have been mentioned is the programmer cost.
>
> With the current Haskell Prelude, a matrix operation (say) mig
At 10:58 12/07/03 +0100, Alastair Reid wrote:
we could have 'context synonyms' like:
class Num a => (Add a, Subtract a, FromInteger a, Eq a, Multiply a, ...)
Adding context synonyms would make it possible to write types concisely when
using fine-grained class hierarchies and would also be usefu
Dnia pon 14. lipca 2003 10:18, Graham Klyne napisał:
> I must be missing something... isn't the effect achieved by:
>class (Add a, Subtract a, FromInteger a, Eq a, Multiply a, ...) => Num a
> ?
It doesn't provide instances of Num for anything which is already an instance
of the other classes
In article <[EMAIL PROTECTED]>,
Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> wrote:
> It doesn't provide instances of Num for anything which is already an instance
> of the other classes. And in Haskell 98 they must be defined separately for
> each type, instance (...) => Num a doesn't work.
On Tue, Jul 15, 2003 at 01:07:12AM -0700, Ashley Yakeley wrote:
> In article <[EMAIL PROTECTED]>,
> Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> wrote:
>
> > It doesn't provide instances of Num for anything which is already an instance
> > of the other classes. And in Haskell 98 they must be de
17 matches
Mail list logo
