Re: Use of ';' in Forth Compiler

First, thanks for the response. It makes the operation of your language a bit clearer than your usual stream of content-free "Forth is dysfunctional!" style statements, because it actually shows your language's semantics and shows what appears to be a valid alternative to the Forth outer interpreter.

John Doty wrote:
OK, you say you *really* wanted to compute "6 7 *" in the middle of a definition and do something trickier with it. I could easily implement "[" and "]": "[" would save the compile buffer pointer, "]" would execute starting from the saved pointer and then restore it. Trivial. A more sophisticated compiler would have to save and restore a little more state, but it's still trivial. LSE64 lacks these only because I see no application-driven requirement for them right now. With IMMEDIATE and SOONER words as well as named constants I have enough tools for build time computation.

Now I'm interested in the actual compilation process and what the form of compiled code is. In the classic Forth DTC model, when a word is compiled, it is compiled at the location where it will reside when finished. In LSE64 (and presumably STOIC), it sounds like you're compiling into a temporary buffer and then copying the code to the final destination.

If that's the case, how do words like "if" work? I would guess that instead of compiling absolute addresses to the "else" and "endif" locations, it would have to store offsets. Otherwise, when the code was moved from the compile buffer to the final destination, you would have to go through a fix-up pass to correct the absolute addresses.

The buffer size is 8k bytes, enormous compared to the size of a reasonable definition, microscopic compared to the gigabyte memories of the machines I run on. The original 1802 version had a 256 byte compile buffer that I never overflowed. Not an issue.

If a fixed buffer bothers you, you could use unallocated dictionary space: it's not especially complicated as long as you don't want to use it for some other kind of temporary array or buffer.

No, I'm not particularly bothered by fixed buffers since it should be rare that anyone would ever create a 8k definition. Of course, that's going to depend on the programmer's style. I'm curious if you keep statistics (or if your compiler can be extended to keep statistics) on the average and maximum length of definitions.

Trivially, as LSE64 is currently implemented, write your code to a temporary file and then load it. Or for the cost of a couple of lines of new system code I could give you a word to take input from a string in memory. Implementation of things like this is easy, but again, I'm application driven. I'm not putting in things my applications don't require.

I certainly don't have a problem with you keeping features out of your language that your applications don't require. What I'm more concerned with (and why I'm asking these questions) is that if the semantics of LSE64 (and presumably STOIC) don't have a way to handle those features, then although you might not run into these limitations, others will.

It's much the same concern I have with ColorForth or any language that is designed around a specific set of applications. On the one hand, having a language that matches perfectly the needs of an application is ideal. But the downside is that the language may have limits for *other* programmers. And that's only a problem when the author of the application-limited language claims their language is the greatest thing since sliced bread.

Regardless, as long as LSE64 (and presumably STOIC) have some means to handle this kind of metaprogramming (even if you personally don't have a need for it in your applications), then it is still interesting to me.

Fourth: Does your language have the equivalent of immediate words?

Yes. And SOONER words. Described above. 

Again I'm curious:  Are there any other classes of words?

Thanks again for taking the time to detail these things. Regardless of if you choose to release LSE64, one thing that might be helpful is a user manual. If others are using your language, I presume you have some sort of manual in some form. Could that be made available?
.

Relevant Pages

  • Re: WANTED: InfoWorld Editorial, August 18, 1980, Vol.2, No.14, p.8
    ... Although CBASIC is not an optimum language, ... compiler before any error checking is performed, ... in order to run both new applications and previously-purchased ... the interpreted and compiled BASICs, ...
    (comp.os.cpm)
  • Re: "STL from the Ground Up"
    ... high-level intermediate language than can interoperate with many other ... If your language lacks expressive features then you cannot write code ... memory management in comparison. ... Mostly because type errors mean that the programmer and compiler disagree ...
    (comp.programming)
  • Re: Linked Lists debugger question
    ... With C++/CLI extensions, you can use this RAD paradigma for building GUIs ... I don't think I will be doing any web based applications. ... It has both a very good IDE and a very good C++ compiler. ... it still the language of choice for develloping PC based applications? ...
    (microsoft.public.vc.language)
  • Re: A note on computing thugs and coding bums
    ... It would handle international characters if the execution character ... method I used in "Build Your Own .Net Language and Compiler". ... work areas and counting on Nul is an illusion. ...
    (comp.programming)
  • Re: access(FULLPATH, xxx);
    ... with "trial& error" to just silence the compiler. ... void *foo); ... given that the language in the specification _was_ abiguous and both ... documentation was paramount. ...
    (freebsd-questions)