Re: [Gnu-arch-users] Re: arch roadmap 1 (and "what's tom up to")

[Tom Lord]

    > From: Samuel Tardieu <address@hidden>

    > Tom> Aside from obvious things like basic data types (numbers,
    > Tom> characters, strings, lists, etc.) I intend to define a minimal
    > Tom> run-time system with support for I/O, lexical analysis, parsing,
    > Tom> and minimal debugging facilities.  As in Forth, these will be
    > Tom> used to define a semi-standard "outer-interpreter" or "repl": a
    > Tom> standard (extensible) program which interactively (or from a
    > Tom> file) reads and executes commands, one by one.

    > Do you intend to make all this available from Furth itself? If this is
    > the case (I hope it is :-), do not make the same mistake as Forth
    > which doesn't provide you with a portable way of overriding the number
    > handling routine (i.e., you can define your own language in Forth for
    > example to implement a cross compiler, but you can't redefine number
    > effects -- such as "if you find a number push it on the target stack" --
    > without rewriting an outer interpreter).


There isn't really a compiler, per se, in core Furth: there's just a
reader.   Unlike forth, there's no distinction between "compiler mode"
and "execute mode".

So when the reader reads a lexeme that spells a number:

        123

that just creates an instance of an exact integer, 123.   If you try
to execute an exact integer as a command, it pushes itself on the
tuple stack.

What would you have different there, and why?   Should the reader 
have an option so that the lexeme "123" produces something other
than an exact integer?   What, and why?   Should there be a global
hook that allows you to replace the self-pushing nature of _all_
numbers to be something else?   I have trouble imagining a clean use
for that feature and fear that it's run-time expense would outweight
any benefits it might have.

-t