[<<][staapl][>>][..]
Tue Jun 10 19:56:35 CEST 2008

next

org:

let's see.. the real problem with org is that it permanently changes
assembly state. currently it's possible to set the org of a chain of
code, which is a local effect only.


asm:

monitor doesnt assemble.. problem with 2stack <-> compilation-state
confusion in evaluation of target values.  the error happens in
/home/tom/staapl/macro/instantiate.ss:80:3 wrap-macro/mexit which
means a .f generated macro is evaluated. ok, it's a constant that's
evaluated with macro->data.

it should be possible to convert macro->data so it runs on a dummy
compiler state, but the real problem here seems to be: is it somehow
possible to not wrap macros with local exit if they don't need it?

well.. i can always run it once, then decide on how to encode it. a
macro can throw an error, but it is not allowed to have other side
effects.

problem:

    the m-exit mechanism makes it impossible to evaluate macros on a
    2stack state, which is possible for most 'clean' macros.

    should the concept of 2stack macro be discarded? or is the concept
    of clean macro important? (don't you just love dynamic typing!)

intuition goes towards: keep 2 classes because the compilation-state
class deals with 'lowlevel' features like multiple entry and exit
points.

is it possible to more clearly separate these 2 classes?l



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