Bradley Lucier wrote:

Marc:

I have some questions about tables.

1. Can there be a function like

(table-update! table key (lambda (#!optional (value default-value)) <whatever>))

instead of using

(table-set! table key ((lambda (value) <whatever>) (table-ref table key default-value)))

It would seem to avoid one table lookup for the key.

I've wished such a procedure would exist, too.

2. I presume that the table can get messed up if the keys are

mutable and you change the key (like a string) after it has been used to index the table. Or is it possible to tell the table to copy any keys that are not in the table as they are entered into the table?

- how would the table code know how to copy the object if it's not necessarily a string? I suppose that (without giving a clone procedure explicitely) it were only clean if there were a general object-clone function. That almost calls for an extensible object dispatch (object system). (Which makes one wonder, if it's a candidate waiting for a module/object system..)

- I've been tempted to say, "couldn't you live with a variant (wrapper) in a library?"; but I realize that always copying the key in table-set! calls would be wasteful in the case where the key already exists in the table, and there's no real way knowing whether that's the case in advance. So there would be a need to expose the table functionality in finer granularity, or really offer it in the existing implementation. If the latter, I'd suggest defining a clone procedure (as argument upon creating the table), which wenn defined, gets the key as argument and returns a clone; if undefined, take the old fast path.

Christian.