On Wed, 28 Apr 2004, Nicolas Cannasse wrote:
> > On Sun, 25 Apr 2004, Henri DF wrote:
> > > thanks for the pointer. i (naively) thought that anything which "takes
> > > away
> > > polymorphism" could only improve efficiency, and that this would extend
> > > functors.
> > >
> > > [OT] i wonder when there is ever a case for functors then..
> > >
> > On my wish list: int, bool, float, and char modules. These would take a
> > lot of the pain out of using functors.
> You forgot :
> (int * int)
> (string * int list)
> (int * char * bool)
> Since there is so much (infinity) core-types, we can't declare module types
> for all of them, so set is broken :'(
This is a slipery slope argument, which is false if there is a clear break
point, a point where taking the next step does *not* automatically follow
from the previous steps. In terms of proof by induction, if is a point
where step n+1 is not necessarily true simply because step n is true, the
proof doesn't work.
Now, there is a break point between int and int*int. A tuple is a data
structure, along with a list, an array, and a tree. When you say the data
structure outloud, you say the word "of"- it's a tuple *OF* an int and an
int. The types I listed are "simple" types, not comprised of other types.
You don't use the word "of" in describing them.
Well, string is a gray area by this definition. The phrase "string of
char" makes some sense. But I note that the standard lib already provides
it for us- the String module works. Try it:
Module StringSet = Set.Make(String);;
So that's my disproof. Simply because we provide int, float, char, and
bool modules, this doesn't imply that we should provide list, array, or
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
- Gene Spafford