pf_main questions

[mschwartz]

The code in pf_main.c that processes argc/argv doesn't make total sense to me.

You have a loop that processes argc arguments. If preceded with a -, you handle the flag(s). But if it's something like a string, you set SourceName to the argument.

Thus if you do something like:

./pforth foo bar

It tried to load bar and foo is ignored.

Maybe we can be a little more clever? How about, "load foo, execute word bar?"

But you also have to deal with:

./pforth foo bar baz

Should it execute words bar and baz?

Or maybe we do something even better.

./pforth foo -ebar baz

This loads foo.fth and runs word bar and passes baz as a command line argument to the forth code to be processed (like we do argc/argv in C).

Even better is:

./pforth foo -ebar -ebaz arg1 arg2

This loads foo, executes bar then baz, and passes arg1 and arg2 as argc/argv to the forth program

Also, maybe better to use getopt() ? (man 3 getopt) - exists on linux and macOS. This getopt() helper is really slick. It allows you to do '-efoo' and '-e foo' and does the right thing. Using it would also allow us to have something like ./pforth -h that prints out help on the command line options.

Windows is the internet exploder of operating systems ;)

[philburk]

Thanks for the suggestions.

It tried to load bar and foo is ignored.

I should at least error out if that happens. I will fix that.

Because Forth can combine compiled and executable code in a file I figured it was enough to load a file.

Sometimes I pass commands to pForth. I usually do that with a pipe. For example:

echo 'include somecode.fth   do.something   bye' | ./pforth

Also, maybe better to use getopt() ? (man 3 getopt) - exists on linux and macOS.

The "p" in pForth is for "portable". That is the primary design goal. There are other Forths that only run on certain systems, or that requires pre-processors like M4. I am trying to avoid as many platform dependencies as possible. PForth was originally designed for running on a Verilog model of an SOC with no operating system. So it is very minimal.

[mschwartz]

I realize the purpose of pForth, to be minimal, but you do have #defines and #ifdefs to support Linux and Unix platforms. Adding getopt support for those platforms would be of huge value.

For generations, the ls command has been what we use to get directory listings. Guys are replacing commands like ls with exa and cat with bat, both (and more) written in Rust.

These kinds of commands could be written in a small amount of Forth and be very competitive with the Rust programs.

Without access to command line arguments, it’s impossible.

just my humble opinion.

[mschwartz]

I’m ok with doing a pr for this.

Other obvious things missing are termios, malloc and free, open read write close, and signals (to get window size, control-c…), access to env variables…. Separate PR :)

I would love to see wordlists, but that’s beyond my expertise at the moment.

As an aside, there is no package manager for Forth, that I know of. I always thought it would be neat if the interpreter could locate words in some repository and optionally run those. That is, foo is undefined so look in repo for foo and download and include it. Security is a huge issue, though.

[mschwartz]

PR here: https://github.com/philburk/pforth/pull/134

[philburk]

Does your PR compile on Windows and non-posix platforms?

termios, malloc and free, open read write close, and signals (to get window size, control-c…), access to env variables…. Separate PR :)

malloc and free are implemented as the standard words ALLOCATE and FREE from ANS. If there are ANS standard words that are missing that would like to see implemented then please let me know.

https://forth-standard.org/standard/words

[mschwartz]

I didn’t test on windows - no development environment. Don’t have any non posix platforms with dev tools either. Though I have done some SoC programming myself.

if you’re assuming argc and argv, then the posix stuff would just work, no?

[mschwartz]

No unistd on windows, so we need to add #if for windows, too.

[mschwartz]

I just pushed the fixed pf_main.c with checks for embedded and WIN32 (is that still a thing?) to avoid the new getopt() logic if those are set.

Built and tests run as expected.