Re: Scheme style auto-resizing hashtable (fwd)

[Tel <telford@eng.uts.edu.au>]

> > For that matter, one could make up similar arguments against
> > insert!/lookup/remove!, e.g.: 
> > 
> > * insert! implies adding a new element, but it might in fact be
> > changing an existing element. set! expresses this much better
> 
> okay.

But in guile, set! will not create a new variable,
you need define! to do that...

Similarly, vector-set! will not exend the length of a vector to
contain an extra element, you get an out of range error if you try.

Thus, set! implies not that you may be changing an existing element
but that you MUST be changing an existing element. I would say that
using a similar name for a subtly different idea is worse than using
a different name altogether. Probably ``lookup'' should be changed to
``ref'', but even in this case, should it be an error to ref something
that doesn't exist or should it return #f? For my work, returning
#f is far more useful than throwing exceptions since I'm can use
a (cond) to scan several options.

> > Really, the choices between these are close to arbitrary, hence
> > consistency with existing practice should be the deciding factor.
> 
> well, let's wait and see what other collection data structure authors
> decide to use.  I'd like to be consistent with their naming conventions.

I'm waiting for you to decide... BTW: if anyone want's to tinker with
any of my code, my web site is up to date (but the server is still unstable)-:

http://www.progsoc.uts.edu.au/~telford/samples/guile/

Source code for all of my stuff is up there, a win32 binary for
my stuff statically linked with guile 1.3 is also up there
(compiled with the mingw32 version of egcs, it should need no special
libraries but lots of stuff is disabled, like regex, dynamic link, posix).

I'm cool about people ripping what they want out of my code for other
GPL projects. Current status is that the B-trees are quite stable and
fast to access (but slow to load). The documentation goes to info and
postscript and is pretty bare bones. The matrix library has basic functions
enough to solve linear equations (fast for symmetric matricies using
ICCG, much worse for non-symmetric using a non-pivoting Gaussian).

When we have a workable module system, I'll split the bits up by
function and not make the distribution so monolithic.

OK, end of personal plug.

	- Tel