Re: goo is missing...

[Jonathan Bachrach <jrb@xxxxxxxxxx>]

"James Knight" <jknight@fuhm.net> writes:

> > 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.

i'm getting there...

> > 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.

right.

> > 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.

why not just search the reversed sequence or return all successful
keys and take the last one?  unless advance optimization are in place,
these options seem heavyweight.  i agree, though, that there's got to
be a better way.

> > 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?

yes if you used mutable sequences you might still want to do
searching.  i guess you could say to convert them to immutable
sequences first but i'm not sure that's a satisfactory answer.

> 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.

right.

> > 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. :)

key-test is exported from goo/cols/col and goo

> > There was a #6, but I have forgotten it by now :)