The two-class trick helps us indirectly write desirable
multi-parameter classes with functional dependencies or
overlapping. The example below happens to have both. The example
illustrates that an attempt to write desired instances directly runs
into problems of bad overlapping or violations of fu
In message <[EMAIL PROTECTED]
com>, [EMAIL PROTECTED] writes:
>it is nice to use 'maybe', 'either' functions. However, with data types
>with more than 2 constructors, using such function tends to be tedious than
>pattern match, where, you can pick specific constructors of interest.
>
>And in order
> Don't export your data constructors because you then expose the
> internals of your module, which is bad for abstraction; export function
> names which serve as the data constructors instead.
Actually this is another thing that I'm wondering about.
it is nice to use 'maybe', 'either' functi
On Tue, 15 Jun 2004 12:05:46 +0100, Graham Klyne <[EMAIL PROTECTED]> wrote:
At 11:30 15/06/04 +0200, Wolfgang Jeltsch wrote:
I'd say, classes in Haskell are similar to interfaces in Java.
I started my Haskell programming with that viewpoint, but got tripped up by it.
A Java interface can be used as
At 11:30 15/06/04 +0200, Wolfgang Jeltsch wrote:
I'd say, classes in Haskell are similar to interfaces in Java.
I started my Haskell programming with that viewpoint, but got tripped up by it.
A Java interface can be used as a type in its own right, but a Haskell
class cannot. For example, you can
On Tue, Jun 15, 2004 at 11:30:24AM +0200, Wolfgang Jeltsch wrote:
> Am Dienstag, 15. Juni 2004 04:05 schrieb John Meacham:
> > [...]
>
> > now classes are a bit trickier, the main thing is that classes in
> > haskell are not like classes in other languages. A class in haskell is
> > nothing more t
Am Dienstag, 15. Juni 2004 04:05 schrieb John Meacham:
> [...]
> now classes are a bit trickier, the main thing is that classes in
> haskell are not like classes in other languages. A class in haskell is
> nothing more than a construct allowing you to reuse the same syntax on
> different types. (t
John Meacham wrote:
1. define the data structures you think you will need or
2. define the class/interface your data structures will have
if you want to take the "prototyping" route,
then indeed do 1. first and then 2.,
but of course first 2. then 1. gives better code
right from the start.
I mean,
On Tue, Jun 15, 2004 at 07:35:44AM +0100, Alastair Reid wrote:
> I don't think I agree with that at all.
>
> John Hughes' "Why Functional Programming Matters" makes it very clear how much
> power you gain from adding intermediate data structures.
>
> I personally find them extremely valuable in
"Tim Docker" <[EMAIL PROTECTED]> writes:
> Of course... that was my second alternative error strategy. I'm
> interest in how/when people decide when to throw exceptions versus
> when to thread errors using monads, given that changing code from
> one to the other could be quite a big deal.
I gener
10 matches
Mail list logo
