Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #55986

Re: one of the ways ANS-Forth was purposely crippled

Show all headers | View raw

On Monday, March 20, 2017 at 5:37:13 AM UTC-7, Helmar Wodtke wrote:
> > I wrote a LITERAL that compiled the number into TARG memory but I had to use this explicitly:
> >             : test  [ 12345 ] literal ;
> 
> Mhm,
> 
> it's best to write your own outer interpreter. It's not complicated. 

Well, my document says (shown above) that using the built-in outer-interpreter is not possible because ANS-Forth does not vector LITERAL 2LITERAL and FLITERAL, and the Forth-200x committee also refuse to do so --- because of this, it is necessary to write your own custom outer-interpreter.

This is complicated though! For a long time, I believed that this was impossible. The reason is that FIND is ambiguous. In VFX, SwiftForth and Gforth we have FIND working in a different and incompatible manner. If you think this is not complicated, then most likely you have only used one ANS-Forth system and you figured out how FIND works on it, but you didn't realize that FIND doesn't work the same way on other ANS-Forth systems. If you are going to be vendor-specific, then you might as well use VFX and use the built-in outer-interpreter --- this is possible in VFX because CLIT, that is used by LITERAL and 2LITERAL is deferred --- this is not documented in the VFX manual however, so you would have had to disassemble VFX to find out about this.

So, the next section in my document describes the disambiguifiers. With the disambiguifiers, FIND begins to work consistently between ANS-Forth systems. This was a major breakthrough for me! Only when I figured out the disambiguifiers did I believe that it was possible to write a cross-compiler in ANS-Forth. Many people claim to have written a cross-compiler in ANS-Forth (you apparently are one of them) --- I don't believe any of them are telling the truth --- I think all of them have vendor-specific implementations (if they don't know about the disambiguifiers, then they have to be relying on one specific interpretation of the ANS-Forth document in regard to how FIND works).

After you have the disambiguifiers, you still have the problem of needing a STR>NUM function. So, that is the subject of the next section in my document. I have a STR>NUM that works. Also, I got rid of the bugs in the ANS-Forth design:
1.) ANS-Forth allows a dot anywhere in a number to indicate that it is double-precision. For me, a dot indicates that the number is floating-point. I allow commas anywhere in the number, but a comma at the very beginning (left side) indicates that the number is double-precision.
2.) ANS-Forth requires an 'e' to indicate that a number is floating-point. I have a dot indicating that a number is floating-point and the 'e' or 'E' is only used when there is an exponent part.

I considered STR>NUM to be a pretty complicated function to write --- maybe you think it is trivial though.

> In the case of writing a cross compiler, you probably even want your own interpreter.

I can't think of any reason why I would want my own outer-interpreter --- my MFX used the built-in outer-interpreter and it was pretty simple and straight-forward --- the only problem was the issue with LITERAL not being vectored.

> I personally prefer interpreters like
> 
> : INTERPRET ' EXECUTE RECURSE ;
> 
> (I know, line endings etc. needed in DPANS are not in scope here...)
> 
> In this case you should have "tickable" literals... And ";" should compile jumps to last "called" word in definition...
> 
> "tickable" literals may have limited life-time for the returned xt. You can implement (pseudo code) like:
> 
> variable last-literal
> : the-literal last-literal @ mode @ if postpone literal then ; immediate
> 
> The "tick" should return xt of "the-literal".

In Straight Forth I can't have tickable literals because I want to support ITC and I don't want to allow new primitives to be made (there is no CODE definer and assembler, so the user can't write his own primitives). All the primitives have to be written by me as part of the system. To have tickable literals, it would be necessary to create a new primitive for each literal.

I don't know why you say: "a tickable literal may have a limited life-time for the returned xt." That doesn't make sense to me at all. I also don't know why you made your tickable literal an IMMEDIATE word. I would have something like this:

code 12345  
    sub rbp, 4
    mov 0 [rbp], rbx
    mov rbx, 12345
    next,
end-code

> The "power" of DPANS94 is not that you get a system that fits your needs - you get a system that is more or less something that behaves as expected by the document. There is no reason why not to modify the system in a way that fits your needs.

You can't modify an ANS-Forth system to have a vectored LITERAL --- you can't use the built-in outer-interpreter because it uses the built-in LITERAL which you can't change.

ANS-Forth doesn't fit my needs. I think that ANS-Forth was purposely crippled to prevent it from being used for writing commercial software. Elizabeth Rather has repeatedly said that the goal of ANS-Forth was not portable programs, but rather portable programmers. What she means is that Gforth would be a toy language that students could learn Forth on. Gforth would not be competitive with SwiftForth or VFX however, so it couldn't be used for writing commercial programs. The student would then be "portable" in the sense that he could get a job writing SwiftForth or VFX programs. These programs would be vendor-specific --- they would not be ANS-Forth --- but the student would have already learned the basics (what DUP and SWAP do, etc.), and wouldn't have to learn this ultra-basic Forth on the job.

> My HelFORTH had - beside it's own very special implementation details - a very compatible DPAN94 layer... I do re-write at the moment the system with some similar ideas. Now I do more DPANS compatiblity from the beginning, but I use only some words (reduced DPANS94 word set). The implementation is again focused on implementing a JIT-compiler later again.

I would be interested in looking at your HelFORTH --- can I download that? --- does it work under Windows?

> Regards,
> -Helmar

Thanks for responding politely! Normally ANS-Forth enthusiasts just respond with a lot of insults. Stephen Pelc says: "RTFM!" in regard to SYNONYM for example. And, of course, there is the 4-year-old saga of Alex McDonald telling me that I "have a serious misunderstanding of how pointers work." All of that gets tedious and depressing --- just not that amusing after the first few years...

Back to comp.lang.forth | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

one of the ways ANS-Forth was purposely crippled hughaguilar96@gmail.com - 2017-03-19 16:46 -0700
  Re: one of the ways ANS-Forth was purposely crippled Helmar Wodtke <helmwo@gmail.com> - 2017-03-20 05:37 -0700
    Re: one of the ways ANS-Forth was purposely crippled hughaguilar96@gmail.com - 2017-03-20 18:37 -0700

csiph-web