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 list.
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
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 convenient and
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:
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
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
