💾 Archived View for bbs.geminispace.org › u › karel › 5335 captured on 2023-11-04 at 16:07:08. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-09-28)
-=-=-=-=-=-=-
Re: "Loading files in nForth: implementation"
@stack: I faced a similar problem in a pet project of mine. My decision is to drop it and let the "user" (that's me) use the C preprocessor in order to gather all the code into one file. As an alternative he (me) can supply multiple code files at the command line. Disadvantage: impossible to output correct file_name:line_number error messages with CPP #includes. Advantage: separation of concerns, old-skool Unix-style. What do you think about this solution?
2023-09-15 · 7 weeks ago
@karel, that is fine if it works for you, and I could've had the assembler append other forth files (it alread appends 'nforth.f'). But it turned out to be dead simple:
: included; \ (fname,cnt--) drop zero dup rot osopen pop drop \ do not return to brace loadh ;
And in the process I got the sync/abort logic working.
So I do append one file, nforth.f, which normally defines included; and uses it to bootstrap itself by loading nf.f. But the user can stuff anything into nforth.f, say for a single file CGI script.
Loading files in nForth: implementation — Having implemented the normally-compile semantics I discussed in the previous post, I must now tackle the `include` functionality to load more forth code from a file. The problem: since nForth is now a compterpreter (it compiles code and runs/erases it to simulate interpretation), we must compile and run the loading code and the filename into the dictionary to execute the load. If we blindly load on top, the pseudo-interpretive block of code that does...