First try (was: Re: Re: willing to help)

hi,

first of all, thanks Tom and Matthew for your advice, which finally
got me started with pika.

i've been reading docs and code (and learning tla,) and finally made a
first attempt at contributing some code, mainly to become familiar
with the project. more concretely, i've implemented hash_fn for
vectors and pairs. it's a very small contribution, hardly worth
noting, but, before going on, i would appreciate if any of you could
take a quick look at it to be sure that i'm on the right path. it is
available at:

Revision: scm--devo--0.1--patch-3
Archive: [email protected]

and it consists mainly on adding a new function (scm_values_hash_acc)
to reps/hash-values-imp.c, and use it in scm_vector_hash_fn and
scm_pair_hash_fn. i've also added tests in separate files
(unit-vector-hash.c and unit-pair-hash.c), rather than modifying the
existing unit-vector.c and unit-pairs.c: is this compliant with our
coding policies? i've observed that 'make test' does not run the new
tests, despite the fact that they're compiled: how do i fix it?

also, i was expecting a reps/vector-impl.[ch] module, but didn't find
it: shouldn't it be there? on a related note, i've observed that reps
uses now and then stuff from libscm, which prevents a clean layering
of both libraries: i was expecting libscm to depend on reps, but not
the other way round, so that we have a nice layered architecture. but
this does not seem to be the case (actually, i've also violated my
proposal when implementing scm_values_hash_acc, but i can easily fix
it): am i missing something?

i was also thinking of implementing the missing
scm_{pair,vector}_equal_fn functions, and actually wrote a first
attempt at scm_vector_equal_fn, but i don't understand the 'issues' in
the FIXME comment: circularity does not seem to be an issue, since
scm_values_equal already tests its arguments using scm_values_eq,
preventing in this way (if i'm not mistaken) infinite recursion when
comparing circular structures (i've in fact tested it for circular
vectors). thus, a very naive impl for vectors that firsts compares
their lengths and, if needed, checks in turn each of their components
using scm_values_equal seems to work--- but then, i don't know what
Tom meant in his comments with the 'interrupts and stack usage'
issues[1]: could you please elaborate on them so that i can try to
provide a robust implementation?

i could also try my hand on reading/writing circular structures. it
seems that the place to handle them is scm_write_value, storing
information about already printed objects in a new field within
scm_write_params (which could be, for instance, a hashmap
t_scm_word * -> index, where the keys are pointers to already printed
objects and the values are indexes for already referenced ones). but i
am probably missing a lot of relevant issues here, am i not?

well, i think that's all by now :) i know that i'm actually wasting
more of your time that my current contributions are worth, but please
bear with me: hopefully, the terms will be inverted as soon as i'm
familiar enough with pika :)

thanks a lot for your help.

cheers,
jao

Footnotes: 

[1]  The actual comment in vectors.c and pairs.c reads:
  /*
   * issues: circular structures, interrupts,
   * stack usage.
   */

-- 
Nature uses as little as possible of anything.
-Johannes Kepler, astronomer (1571-1630)