Participants for the ICFP poster session should sign up by June 30th.
No additional information is required until later...
The 2004 ICFP Poster Session
http://abstract.cs.washington.edu/~djg/icfp-poster.html
Part of the
> Google
> for "per-type function namespaces", which was an idea I sent to the
> list a few months ago, for something which I think better solves the
> naming issue. Quite a lot of people disagreed with it, but I still
> think it's a good idea. (FWIW, I nearly managed to implement this with
>
[Apologies for the slightly long setup. The guts of the question is: can
one use the class system to code up the reflexive, transitive closure of a
set of dynamic (but contextually implied) coercions? I'm coming to the
conclusion that the answer is no, but I'm interested in a good
explaination o
John Meacham wrote:
[...]
I find trying to draw analogies between haskell classes and constructs
in other languages to be problematic as people then try to apply
knowledge from other fields incorrectly to haskell unless you give a
full explanation of haskell classes anyway.. but YMMV.
John
[EMAIL PROTECTED] wrote:
Tom,
Then what will you do when naming operations in a class? Is it right that
care has to be taken in order not to conflict with other classes?
Say, I have a Person class where I want to define an operation "getName".
Is it wise to name it "getPersonName" instead?
Class me
