Thu Jan 31 16:54:05 CET 2008

caching an association list

the problem can be solved by making the operations abstract.

association list:
   * push
   * pop
   * find

as long as the access pattern contains no pops, the caching mechanism
is quite simple. on pop, one could re-generate. this is effectively
what i'm already doing, however, it's not guaranteed synchronized.

so.. the elements: 2 dictionaries:

  (macro)         ;; defined in core, and untouched by prj
  (macro-cache)   ;; cache of prj macros

for this to work, the code in (macro) should NOT depend on the code in
(macro-cache). this means the core macros are not allowed to have
pluggable code. this is only allowed in the static load part.

let's rephrase: macros are subdivided in 2 parts:

  1) declarative with cross-resolve (pluggable components)
  2) linear dictionary extension on top of this

does this in any way interfere with local name re-definitions?

i think i just need to try it out..

re-iterate the model from the forth side:

each compilation unit has a name space that can shadow/extend the
previous one. all extensions in one unit need to be unique.  this
model resembles incremental compilation per word (strict early
binding), but allows for cross-reference within one unit.

 * get rid of constants.
 * get rid of ram dictionary.
 * move macros to target dictionary.

constants already were eliminated. they can still occur in rewrite
macros that generate asm code though.

the ram dictionary is more problematic. it's probably best now to move
to abstract access methods for the dictionary. it does look like
that's the way out. pulling those changes through the assembler will
shuffle things quite a bit. macros can follow quite easily from there.

maybe it looks like this: in assembler.ss -> 'label 'word 'allot
represent the points where the dictionary is augmented. what will
happen here is that macros can be defined also, no?

there seems to be a conflict between allowing the definition of labels
(ram or flash) and allowing those of macros, when they are all

there is a difference however: as long as the thing which creates a
new macro definition, only dumps it in the assembler buffer, there is
no problem.. the entire buffer will be assembled with the current
macro definitions.. wait, there's something warped about that.

pushing through some changes, i arrive at the assembler. it might be
best to turn the running variables (rom and ram top pointers) into
real variables, and use the dictionary as a stack.

going to try to do some things at once:
 - allot needs to be rewritten in terms of ptr@ ptr!
 - adding new dictionaries won't work any more

fading out.. next = (code . 0) (data . 0) etc.. data is missing.

ok, cleaned that up a bit.. also made the running pointers mutable.