New community dev tool uploaded: alpha xForth Compiler

[BruceMcF]

I haven't had time to work on this in the past year, as I returned from China and am now working "more than a full time week" each week ... so it's bugs are still untouched ... HOWEVER, as I hadn't got to the BLOCK system and other things that are intended to use HighRAM and the text I/O is strictly Kernel call based, it seems likely that it won't notice the transition from R38 to R39.

[TheGeekOnSkates]

I *love* Forth! So much so that I started building one for the X16 myself. Then I found his, which is already way more advanced than mine (not to mention 4K less in size), so idk if I'll continue working on mine. I'd kinda rather contribute to his, tho granted my Assembly skills are not at his level (oh I've built decent-sized projects with it, but just don't have the time to learn every trick in the book). I'm enjoying the heck out of playing with this X16 Forth, and I'd be happy to at least test it and provide tutorials and stuff.

Oh yeah, that's what I was gonna say - time. Another type of "speed advantage" for Forth is that, when done correctly, it saves you a TON of time. For example, in C I could do:

Code: Select all

#include <stdio.h>
#include <peekpoke.h>

int main() {
    printf("%c", 147); // Clears the screen on the X16 and Commodore stuff
    POKE(646, 1); // Sets the text color to white on the C64
    printf("Done.");
    return 0;
}

Then I could write a Makefile, and run it, and then fire up VICE and test it. Shoot, even comapred to BASIC...

Code: Select all

10 PRINT CHR$(147)
20 POKE 646, 1
30 PRINT "Done."

Not as many hoops to jump thru as C by any means, but still takes a bit of writing. Or, using Forth (including xForth) I could just do:

Code: Select all

147 emit 1 646 ! ." Done."

Or, if I knew I'd be doing stuff like that a lot, I could get fancy and do:

Code: Select all

: clear 147 emit ;
: white-text 1 646 ! ;
clear white-text ." Done."

Scale that up to big games, and OMGosh what a time-saver! Performance-wise, I'm sure it's better than BASIC (I won't pretened to know enough to be able to argue about 20% or 40% or whatever) but dev-time-wise it's a no contest.

[kelli217]

Of course, address 646 no longer controls text color...

[TomXP411]

Those are also poor choices for BASIC and C examples. Both are outdated and seem intentionally obtuse.

BASIC has both CLS and COLOR statements. So a BASIC one-liner is no more complex than your last line of FORTH:
10 CLS:COLOR 1,0:PRINT "DONE"

In C, the imperative code would be:
clrscr(); setcolor(1); prints("Done.");

Of course, I'd never write it that way. I prefer one statement per-line, which is common in most other languages, so:
clrscr();
setcolor(1);
prints("Done.");

Of course, people hate learning C because "all those symbols, like ! and &". I'm sure they'll love learning a language where the period is the print command and ! appears to be the "write to memory" command.

To be clear, I do see the parsing advantages in a stack interpreter. I've thought about writing my own stack interpreted language. Having programmed on the HP48 calculator, I enjoyed it. It's also perfectly fine to like using FORTH, or any programming language you prefer.

Just... at least be correct when citing counterexamples.

[TomXP411]

Of course, address 646 no longer controls text color...

True... and nobody should POKE to change the text color, anyway, since they can
5 emit

[BruceRMcF]

Advantages over C are when using Forth properly, with a write, test, test, test, rewrite, test, test, test, save unit test, write next word, ... kind of development cycle, that it is typically easier to bench test individual words as you go. That is similar to Basic, but unlike Basic, once the word is compiled, the inner execution of the word is not performed by a program interpreter., so performance is faster.

But there is no such thing as a silver bullet programming language. There aren't widely available namespace management tools & support facilities to handle very large libraries of code, so most professional modern Forths for PC environments rely on external function call support to call DLL's originally programmed and and designed for other langages, and that "designed for" part sometimes undermines some of the development benefits of using Forth.

So if I am doing statistical analysis, I am going to do it in R and go to the R archive project to get an abundance of already developed analytical tools.