[<<][packetforth][>>][..]
Mon Apr 23 22:47:17 CEST 2007

data structures

pf uses single ended deques. maybe that's a mistake, and maybe that's
not even the right name.. the idea is that i only need stacks and
queues, and both are implemented using the same structure.

however, i've been working with lisp more lately, and regret i didn't
use cons cells. but does that make sense? i'm working on a 'linear
lisp' VM. a VM for a pf-like language with linear data structures (no
shared storage). in PF, i don't really do that properly: i use
pointers a lot.

some things are important to me:
* i need O(1) queues and stacks
* preferrably using a single data structure

however, in core PF i often find i need to go back too.. so i probably
need doubly linked lists. funny that i started out not using them
because they are 'inefficient'. maybe that should be the next core
change? if i can't have cons cells, move to double lists. maybe linus
is right? :)

the second core change should be a garbage collector. i think i
understand the problem better now: i know how to mostly avoid garbage
collection using stacks and 'unobservables', but it's too convenient
to miss out on temporary code, and i think the artificial compile mode
/ interpret mode distinction is too archaic.

interestingly, trying to make accesses abstract separates the reading
from the writing. i probably need to rewrite stack.c and list.c to use
only a couple of muting primitives. that's where the core of the
problem is.

so, i fixed up list.c

there's another one thats worse: stack.c

i'm wondering if this really pays off. maybe it's easier to try to
generate the code instead of refactoring it. there are so many special
cases, i don't know where to begin.. and if it will ever end..

this is crazy if i can't automate it.

it's probably better to automate it, and regenerate completely. that's
going to be more interesting anyway, what i just did is slave labour.

one question though: how come i keep falling for this trap? thinking i
can refactor PF, take out the assignments and hardcoded bits.. it's a
bit hard for me to accept i wrote a rigid piece of code. and even more
that i knew i was doing this: for efficiency and simplicity.

in fact, it is quite modular etc, but the data structures are pretty
much fixed, as a result the core is not factored enough, and that's a
thorn. disentangling this is probably too much work, but stays a
challenge, since there's so much knowledge encoded already..

i know that the only real solution is to write a linear subset inside
of a scheme language, possibly as a distributed system: linear core on
appliances, with scheme on the cluster.




[Reply][About]
[<<][packetforth][>>][..]