[<<][staapl][>>][..]
Sat Sep 29 15:51:12 CEST 2007
forth preprocessing
parsing and lexing.
it's divided in a somewhat un-orthodox way
LEXING
there are 2 front ends:
forth-lex :: string -> atom stream
forth-load-in-path :: file,path -> atom stream
the lexing part flattens the load tree. i.e. during lexing, the source
code is made independent of the filesystem.
PARSING
this is where i have to break things, so let's commit first.
1. flat forth stream -> compositional forth stream with macros removed
2. constants -> macros
let's see if i understand: constants are bad. there is no way around
the fact that constant swallows a value: it's the worst case of
reflection. this is not compatible with current parser. keeping it
would require lookahead.
so 'constant' needs to be replaced entirely by 'macro' in source code.
looking at the previous entry [[phase-separation]] what is required is
indeed a parsing step that can translate
1 2 + constant x --> macro : x 1 2 + ; forth
yes, this is of course possible, but is it really worth it? maybe it's
better to clean up the Purrr language semantics now than to carry
around the code that allows this. ad-hoc syntax is a nuisance.
so, current path: CONSTANTS are being removed.
that was easy :)
now, for variables.
variable abc
does 2 things: it creates a macro that quotes itself as a literal
address, and it adds code that tells the assembler to reserve a RAM
slot.
maybe i should use 'create' and 'allot' ?
(back to that later)
currently the parsing seems to work, except for the macro/code
separation step. for this i need a stream splitter. in stream.ss i
have '@split', which just splits off the head of a stream, not true
splitting.
status:
- parsing step: ok
- load! setep: ok (like previous load, but with macro defs separated)
next:
- remove all side-effecting macros
- change the assembler to take values from macros
remarks:
* is dasm-resolve still possible? (value -> symbol)
status:
- monitor.f -> monitor.hex gives the same code
[Reply][About][<<][staapl][>>][..]