[<<][staapl][>>][..]
Tue Jun 5 11:42:11 EDT 2012

Prefix commands

(prefix-parsers-wrapped
 (target) 1cmd:
 (kb))

(prefix-parsers/meta
 (target) live:
 ((1cmd: w)    (t> w)))

Somehow (1cmd: kb) reseolves 'kb' using 'interpret-target', while what
I expect is this to be in live.  The trick here is in the /meta stuff,
which defines prefix parsers in terms of some other interpreter, while
the 'kb' parser itself is defined just as a (target) namespace prefix
parser.

;; Like 'prefix-parsers', but translate code using a different
;; compiler and splice it in.

(define-syntax-rule (prefix-parsers/meta ns lang: (pat code) ...)
  (begin
    ;; Evaluation the pattern to check if the names are actually
    ;; defined, but that doesn't work because it includes pattern
    ;; names as well..
    ;; (begin (lang: . code) ...) ;; test-eval it
    (prefix-parsers ns (pat (,(lang: . code))) ...)))



So, knowing this, how to break the loop?  Looks like it has to be
solved in the (target) namespace because that's where the prefix
parsers are.  So this needs to be solved in `target-interpret'.

Solution seems simple: call `target-interpret' direcly, and add an
optional argument.

Hmm... doesn't seem to work very well.  Interactions are too complex.
Maybe it's better to not define these words as prefix macros.  That
seems to be the real problem.

These could be just words..

Almost there.  This works:
> (target/kb (state:stack))

But when it's typed on the console, the words are not found.  Maybe it
just needs to look in the target/ dictionary first?

Another problem: why are the target words not defined as target/ prefix?

Ok, I see.  Looks like we hust need a different namespace.  What about
sim?

It's probably better to get rid of (target) for any console code, and
use it just for target words.  That's for later cleanup, for now let's
just introduce an extra namspace.  Let's just call it (host).



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