Re: [Pika-dev] Things to hack on?

[Tom Lord]

    > From: Andreas Rottmann <address@hidden>

    > I just wonder what's up next for implementation in Pika; I could
    > imagine hacking on:

    > * List primitives from R5RS (section Pairs and Lists). I'd probably
    >   adapt the implementation from Guile. How should the C API to those
    >   look like? I imagine something like that:

    >   scm_is_list ()
    >   scm_list_length ()
    >   scm_list_reverse ()
    >   scm_list_append ()


scm_is_list () and scm_list_length () might be a good place to start.

There is a bitrotted implementation of scm_is_list at the bottom of in
src/scm/unfinished-code/libscm/pairs.c

The bitrotted version is named scmh_is_list but aside from that, is
the right interface.   The thing currently called scmh_list_length
should be renamed scm_list_ilength.

One idea is to move those to src/libscm, review/unrot them, and write
some tests.   The code in there that does interrupt polling can just
be #if 0'ed out for now (and add a #undef FIXME there too -- to make
it easier to grep for).

scm_list_reverse can work similarly.

It might be worth modifying scm_list_ilength to optionally return the
last pair of a proper list and then use that to write scm_list_append.


    > * A hash data type, based on hackerlabs hashtrees (since this is not
    >   in R5RS, it is probably not high priority). Again, what API? I'd
    >   like to stay mostly Guile-compatible; see "info: (guile) Hash Table
    >   reference".

I'm more inclined to write something analogous to hashtrees in
Scheme rather than wrap the hackerlab version.   I don't _think_ we'll
need native hash tables to bootstrap.   (Symbols already use a
hashtree internally for interning.)


    > * We need a procedure data type. I think this a bit to Pika-corish for
    >   me to implement, but if I get an implementation plan, I might try
    >   it.

Such a plan isn't quite ready yet.    I'm working up to it.

-t