[<<][staapl][>>][..]
Wed Jun 11 09:49:43 CEST 2008

m-exit

ok, another choice to be made.
does 'macro->data' use 2stack or compilation-state or something else?

maybe it can be parameterized?

since it's more about a configuration issue than anything else: when
not using mexit and in-line word creation, use 2stack, otherwise use
the extended compilation state.

ok, something else to clean up:

    state:2stack : create a state object with update function
    make-2stack  : create the raw struct

now, the solution i have is to use a parameter called
macro-eval-init-state, but isn't it better to store this kind of type
information in the macro itself? in fact, this is a universal
property: each scat/rep.ss word has a native type on which it
operates, so let's make that mandatory. the type class can be
represented by a constructor for an empty state.

plan changed:

   * add a new record to words to indicate type. the type is actually
     a state constructor.

   * new-state:2stack -> parameterized constructor
   * state:2stack     -> type value

ha, this doesn't work for compostions! there it needs to be inferred
at compile time, but that's not possible. anyway, i'm going to keep it
to see where it ends up. maybe an order relation for state types can
be defined, so at least this type analysis can be performed at
run-time.

no.. it's too flakey, let's get rid of it.


[Reply][About]
[<<][staapl][>>][..]