Re: new contributed library: <treap>

[Neel Krishnaswami <neelk@xxxxxxxxxxxx>]

Jonathan Bachrach writes:
> Neel Krishnaswami <neelk@alum.mit.edu> writes:
> 
> >   Python is a good model here. It has a fine-grained,
> >   well-documented exception hierarchy, and the std library makes
> >   use of it everywhere.
> 
> i'm on the case.

Cool. goo's exception mechanism is a lot better than Python's, and it
would be nice to use it. :)
 
> > o There are a couple of missing functions from the protocol:
> > 
> >   add-key: (c|<map> key|<any> val|<any> => <map>)
> > 
> >    This is just the dual of del. 
> 
> i guess elt-setter wouldn't be appropriate here because it implies
> side-effecting?  also this name is a bit misleading especially wrt
> to sets.  why would it take a val?  perhaps it should be called
> `map-add'.

I'm not really wedded to the name; I just want the method. Give me a
name and I'll change the module to fit. I was impressed that I only
had to export 3 new names, and getting it down to 2 would be even
better. :)

There's one more fun I found missing last night:

  has-key?: (c|<col> k|<any> => <log>)

It says whether or not a key is in a collection. The reason elt-or
wasn't enough for me was that I was writing a memoized function. So I
needed a way of telling whether or not the args wer in the memo
table. (Adding a new hash table type was really easy, tho -- it was
~15 LOC.)

Here's the implementation I wrote: 

  (dm has-key? (c|<col> k|<any> => <log>)
    (esc return 
      (try ((<error>))
        (fun (cond resum) (return #f))
        (seq (elt c k)
             (return #t)))))

I'm not that happy with it because I have to trap <error>, which is
just too big an error domain. It would be nice if there were a
<key-err> exception to catch, which would let other kinds of errors
pass on through.

> > o That's probably symptomatic of my main difficulty: it's not clear
> >   which methods I must override in order to have a collection that
> >   works reliably with all the collection methods. 
> 
> i would very much like some sort of interface mechanism.  back in the
> day, we definitely had an idea that this could be implemented merely
> in terms of dylan's abstract classes and generics.

It's hard to think how to specify interfaces that are the interaction
of multiple classes in multimethods, though. Maybe the right thing for
goo isn't to think in terms of specification, but to beef up the
reflection protocol on generics and classes to the point where you can
write a function to just *check* whether a class implements an
interface. You have all this info at runtime, so it seems a shame not
to use it. :)

Eg, after writing <treap>, I might call

  (is-map? <treap>)

to figure out whether or not <treap> satisfies the <col> interface.
(Obviously we'd want more info than #t/#f, but this is just an
example.) I guess the thing to do would be to try writing some of
those interface checking functions and seeing what primitives and
macros you really need. I'd like to see what Chris Armstrong is
cooking up....

-- 
Neel Krishnaswami
neelk@alum.mit.edu