From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <8986775bc07178dcbeb4f12677ccf3aa@vitanuova.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] same functions everywhere
From: rog@vitanuova.com
In-Reply-To: <20030508184008.27853.qmail@f.bio.cse.psu.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Date: Thu,  8 May 2003 20:52:23 +0100
Topicbox-Message-UUID: a54e45d4-eacb-11e9-9e20-41e7f4b1d025

> How do you write a generic sort function in Limbo?

there are several ways, most of which would be considered too
heavyweight for a simple sort, but which can be fine for larger
operations when generic behaviour is required (channels and modules
both provide different kinds of dynamic coupling).

as dan says, the new parametric polymorphism will provide a more
conventional way to do it: it's not *completely* generic (the
polymorphism only works on ref adts), but fine for many purposes.

to be honest, low level generic functionality like that doesn't seem
to be actually used *that* often.  (it's fairly unusual to need to
sort more than one kind of thing in a given module).

to be honest, where i've needed to sort something, i just paste in the
following code:

sort(a: array of T)
{
	mergesort(a, array[len a] of T);
}
mergesort(a, b: array of T)
{
	r := len a;
	if (r > 1) {
		m := (r-1)/2 + 1;
		mergesort(a[0:m], b[0:m]);
		mergesort(a[m:], b[m:]);
		b[0:] = a;
		for ((i, j, k) := (0, m, 0); i < m && j < r; k++) {
			if(greater(b[i], b[j]))
				a[k] = b[j++];
			else
				a[k] = b[i++];
		}
		if (i < m)
			a[k:] = b[i:m];
		else if (j < r)
			a[k:] = b[j:r];
	}
}

and define suitable values for T and greater(),
e.g.
T: type int;
greater(a, b: int): int
{
	return a>b;
}

the function itself is byte-for-byte identical with the other places
it's used, and well debugged.

since the actual code doesn't need to change at all, it's easily
verified as being the same as that in other places (and easily
searched for should a bug emerge.  there are a few.

i dislike cut&paste code in other circumstances, but this seems
different (as the code itself doesn't change, and the interface is
very narrow).  maybe i'm hopelessly misguided!

  cheers,
    rog.

PS. the other dynamic features of limbo mean *far* more
to me in terms of writing re-usable, re-applicable and
understandable, reasonable code than the lack of polymorphism.