[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Pika-dev] Re: First try
From: |
Jose A . Ortega Ruiz |
Subject: |
[Pika-dev] Re: First try |
Date: |
Mon, 22 Dec 2003 21:53:49 +0100 |
User-agent: |
Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux) |
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)