Hello Jeremy,
Wednesday, May 18, 2005, 11:06:23 PM, you wrote:
JS> http://www.n-heptane.com/nhlab/
it's the same module i say about :)
License
I did not write this module, and I am not entirely clear on what exactly the
license is. Here is the license reproduced from the heade
G'day all.
Quoting Jérémy Bobbio <[EMAIL PROTECTED]>:
> One of the best bad example is the use of boolean as arguments.
Oh, yes. That's a pet peeve of mine. About 99% of boolean arguments
should be meaningful two-valued enumerated types. It's literally a
one-liner to create such an enumerated
Am Donnerstag, 19. Mai 2005 10:39 schrieb Stefan Holdermans:
> Wukaichen,
>
> > data People = A | B | C | D | E | F deriving (Show, Eq, Ord, Enum)
> >data Pair a = Pair a a deriving Eq
> >
> >instance Show (Pair People) where
> > show (Pair x y) = "<" ++ show x ++ ", " ++ show y ++
On Wednesday 18 May 2005 11:58, Graham Klyne wrote:
> So I ask myself: are there any good papers or books on this topic
> that outline a coherent and principled approach to API design?
Matthias Ettrich's talk at aKedemy 2004 about Qt API was interesting:
http://ktown.kde.org/akademy/Matthias_Ettr
Jerzy Karczmarczuk <[EMAIL PROTECTED]> writes:
>>Finally I found some time to reply to this posting. A couple of years ago we
>>did something called "Data Field Haskell", which is Haskell extended with a
>>generalized form of arrays called data fields. Much of the purpose was to
>>investigate conv
On Wed, 2005-05-18 at 18:19 +0100, Colin Paul Adams wrote:
> I'm trying to download a darcs client, but I get:
>
> "The connection was refused when trying to connect to www.haskell.org"
> from Firefox on Linux.
haskell.org was down for some time yesterday. It's back now and
everything should be w
At 19:39 18/05/05 -0400, [EMAIL PROTECTED] wrote:
G'day all.
Quoting Graham Klyne <[EMAIL PROTECTED]>:
> I think you raise an important point. Reading this, I realize that I have
> no principled basis for deciding what makes a good API, in any language.
Me neither. Though I have short reading lis
