Re: goo is missing...

> So... my professor let me program my research this semester in goo.
> I've found that I've been needing the following:
> 1. egal == for strings and tuples (mostly because of the lack of #4 and
>                                   the advantages it would give for
> 				   <tab>)
>   I think == for immutables has far more advantages than disadvantages.
>   The only disadvantage I can think of is == will no longer be a fast
>   == operator.  Two options come to mind:
>   a. Make an object-== which basically does
>   (== (address-of x) (address-of y))
>   b. If someone wants a fast ==, just have them type that out.

I totally agree. Even though == is the most often called function in all
of GOO, it still needs to do the right thing. Having it be fast is not
useful if it isn't producing the appropriate results. How often do you
actually *want* to compare two tuples for pointer equality? There are
various ways a structural test could be made fast such as storing a
precomputed hashcode and testing that before iterating over all elements.
> 2. Something that produced bugs for me:
> (add!) and (add) do different things.  The first appends, while the
> second prepends.  (add!) for lists prepends.
>
> I think the behavior of add should be more consistent.  When I call
> add, I expect things to be added to the end.  Otherwise, when I make a
> function that takes a <seq> and uses add, if you pass it different
> types of <seq>'s, it will have a different result.
>
> This will make (add!) slower for lists, but who uses lists anyway?

Definitely. I suspect that's just left over from the transition away from
lists and was overlooked.
> 3. Reverse (pos) and reverse (finds)
There must be some way of doing that which doesn't require duplicating
every function that iterates over a sequence and returns the index.
> 4. Being able to define what equality function to use for mem?, split,
> pos, finds, and pretty much every other <seq> function that uses it.

I have a few thoughts about that:
a) if #1 was implemented is it still really necessary?
b) actually adding that to the API would cause excessive bloat without
optional keyword arguments, and perhaps even with.c) for some of those, it is not really even necessary. For instance,
instead of mem?, use any? if you want to use an alternate test function.

> 5. case-sensitive string hashing
You can do that, but it's not really well supported, or documented. As
I've said before, <str-tab> really ought not be in the public API at all.
All you need to do is make a subclass of <tab> and override the key-test
and tab-hash functions, only one of which is exported from the
goo/cols/tab module. :)
> There was a #6, but I have forgotten it by now :)