[Pika-dev] What's on my plate for Pika...

[Matthew Dempsky]

I just thought I'd let everyone know what I've been working on Pika
over the past few days:

  * Finishing implementing numbers- I've been refactoring a lot of
    code to get rid of some unnecessary temporaries, but in the
    process realized I've openned up a nasty possibility for aliasing
    bugs (bignum and bigrat constructors) so I'm going to need to
    clean up those aspects a bit.

    The remaining functionality that's missing I have strong ideas on
    what to do too, so while I don't want to give anyone the
    impression of "this code is mine - stay out", I just want to avoid
    redundant work in the area.  Until the code has stabilized a bit
    more I'd recommend bugs just be pointed out to me in case I'm
    already aware of it and have something planned.

  * Simple garbage collector - I mentioned this earlier and I still
    need to upload the code (which I'll try to do later tonight after
    my last class).  Once this is up, it'll probably be ready for
    hacking on by anyone interested.  (It's entirely localized to
    gc-arena-imp.c, but could use some looking over since the severely
    overloaded use of t_scm_word inside reps/ boggles my mind
    occasionally.)

  * Simple REPL - While it's not code that will probably make it into
    Pika without some revamping, I've ported a lot of the explicit
    control evaluator from SICP over to C using Pika's FFI.  It uses a
    gcc extension (labels as values), but maybe someone could hack
    that away.  I wanted to get this working primarily as an easy way
    to test the GC and numbers, but maybe it could be useful for other
    stuff.  (Again, I'll try to get this available later tonight.)

  * Porting Pika's FFI - I haven't actually started this yet, but I
    talked with Scott Miller (aka FoxFire; SISC developer) and he
    expressed interest in having Pika available as a C FFI.  To quote:

        "That would be fantastic.  I would almost certainly add it to
        the official distribution.  [...]  We don't have a C FFI, so
        it would be good to have until there is a decent FFI SRFI (50
        doesn't yet count)."

    I have zero familiarity with JNI so this will have to be held off
    for a little while, but it might serve as a proof of concept and
    add weight to Pika as a standard for a C FFI.

    I also wanted to look at Guile's FFI to see if it would be
    possible to wrap easily, but because Pika and Guile both use the
    scm_ prefix, there'd have to be some magical way of doing it.  For
    example, both define scm_make_complex but in Guile it's
    prototyped as:

        extern SCM scm_make_complex (SCM real, SCM imag);

    while in Pika we have:

        extern t_scm_error scm_make_complex (t_scm_word * result,
                                             t_scm_arena arena,
                                             t_scm_word * a,
                                             t_scm_word * b);

    Maybe one of our resident Guile experts could give some insight?

Alright, that's all - I hope I'm not stepping on anyone's toes with
all this.  If so, I'll go ahead and just make available what I have
and maybe it could be of a little use.

-jivera