[330] 2024-01-06 15:25:11 lmr wrote:

example - "make the user input device the input source"

Since QUIT is bound to reset the input source, what's a "clean" way to handle, say, command-line arguments (like -e or file arguments in Gforth)? Of course there are plenty of hacks to come up with.

[r1167] 2024-01-06 07:34:58 AntonErtl replies:

requestClarification - throw code for compiling outside a definition

There is no established throw code for compiling outside a colon definition, so you can choose a system-specific one, if you want to throw an error (most systems don't).

Concerning state, the existence of '[' and ']' means that state @ does not tell you at all whether you are inside a colon definition. E.g.

: myliteral postpone literal ; immediate \ myliteral has interpretation semantics
: mycompile, compile, ; \ mycompile, has interpretation semantics
: test
  [ 1 myliteral ] \ compiling inside a colon definition in interpret state
  [ ' + mycompile, ] \ compiling inside a colon definition in interpret state
;
] + [ \ compiling outside a colon definition in compile state

Everything but the last line is a standard program, the last line is non-standard.

[r1168] 2024-01-06 07:54:21 AntonErtl replies:

requestClarification - are colon-defs supposed to be compiled in data space?

I don't find it written clearly enough in the document (Chapter 3 is what I looked at), that's why I leave this request open; in particular, the document says very little about code space and does not say that compile, allocates in code space or that the compilation semantics of various words allocate in code space.

Anyway, the intention is that the current definition and the stuff that is appended to it lives in code space, except the header which lives in name space (which, as has been noted, is in conflict with he usual meaning of "name space" in programming languages). Both name space and code space may be interleaved with each other and with data space, but they can also be separate. Traditionally, they are interleaved, but for a native-code system I recommend separating out at least the code space, because writing to data close to code causes serious performance penalties (I measured 400 cycles per ! at one point).