[Pika-dev] Re: First try

[Jose A . Ortega Ruiz]

Tom Lord <address@hidden> writes:

>     > Revision: scm--devo--0.1--patch-3
>     > Archive: address@hidden
>
> I'l take a look at that on monday.  You need to mention the location
> of your archive, though.
>

sure. in the meantime i've made a patch-4 revision fixing a couple of
obvious bugs in my previos imp:

Revision: scm--devo--0.1--patch-4
Archive: address@hidden
    sftp://address@hidden/home/jao/public_html/{archives}/hacks04

>     > also, i was expecting a reps/vector-impl.[ch] module, but didn't find
>     > it: shouldn't it be there? 
>
> No, and in fact, I'll probably move your code out of
> reps/hash-values-imp.c and into libscm.
>

as you see fit, but how so? the code in hash-values-imp.c has nothing
to do with vectors...

btw, my current implementation of scm_pair_hash_fn calls, as advised,
scm_value_hash_depth without modifiying the depth param. if i
understand what's going on properly, that makes that only the first 3
values in a list contribute to it hash code. a quick fix (broken for
circular lists) would be to use (depth + 1) instead of depth. comments?

> reps provide the lower level `vtable' meta-type and there can be
> alternative implementations of that -- but vectors are generically
> implemented on top of vtable objects.
>

i see.

>
> It is nicely layered -- just not the way you expect.  "Encapsulated"
> might be a better word than layered.
>
> Basically, the lowest level details of object representations go in
> reps.   The next-up level of details about number representations goes
> in libscm-numbers-reps.   Those two directories are supposed to permit
> multiple implementations but present stable interfaces.
>
> Everything else goes in libscm and libscm-numbers and hopefully only
> needs to be implemented just once.
>
> It's just the nature of the beast that calls happen in both directions
> -- but the calls in either direction are at least to fixed APIs.
>

ok.

> [crystal-clear explanation of circularity issues snipped ...]
> 
> In the low-level primitives currently being written, the plan is to
> permit interruption by having those primitives periodically poll and,
> if the poll says there is an interrupt pending, return an error.   I
> haven't yet put in the polling code -- so please just leave a "#undef
> FIXME" there for the circularity issue.
>

i see now. so, it is worth writing a naive implementation of equal
then? or should i wait until the poll mechanism is in? i could even
try to implement it if you could give me a little more detail :)

>
>     > 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?
>
> That should wait at least for vector-based hash tables -- but most
> probably circular read and write will be coded in Scheme and compiled.
>

good. tackling with circularity i much cleaner in scheme than in c.

>
> I don't feel that my time has been wasted.   Thanks for your help.  I
> hope my answers aren't to horrible. :-)
>
not at all. on the contrary, i'm already learning a lot, which was
one of the points of my contributing :) talking of which, what do you
think i could try my hand at next?

jao
-- 
I shall be telling this with a sigh / Somewhere ages and ages hence: / Two
roads diverged in a wood, and I -- / I took the one less traveled by, / And
that has made all the difference. -Robert Frost, poet (1874-1963)