Redesigning Forth

[JimBoyd]

IamRob wrote:

The FORTH I am working with is pretty incomplete. But it is the best one for the Apple so far.

Is this one you are writing? If so, which standard are you following?

[JimBoyd]

GARTHWILSON wrote:

(ANS prefers MARKER; but MARKER requires planning ahead more.) FORGET is included in the ANS Programming Tools word set, with a note saying, "This word is obsolescent and is included as a concession to existing implementations."

I don't see that MARKER works any better than a well designed FORGET. Gforth is an ANS Forth for Linux. Here is the result of a little experiment I ran:

Code: Select all

Gforth 0.6.2, Copyright (C) 1995-2003 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit
marker bozo  ok
: (emit2) dup (emit) (emit) ;  ok
' (emit2) is emit  ok
char a emit  aa ok
bozo   ok
: really.long.name cr ." This is a really long text string to smash (emit2) and I hope it works." cr cr cr cr cr ;  
*the terminal*:6: Undefined word
: really.long.name cr ." This is a really long text string to smash (emit2) and I hope it works." cr cr4cr cr cr ;

uncaught exception: Invalid memory address

As you can see, Gforth 0.6.2 has no protection against forgetting ( via MARKER ) the vector of a deferred word. Hopefully, newer versions have such protection for deferred words in the core system ( what I call the Forth Kernel ).

[IamRob]

GARTHWILSON wrote:

IamRob wrote:

I now wonder if it is possible to remove a word in the middle of a dictionary, then have every word that comes after that removed word, to be decompiled and recompiled at its new address? Will start another thread for this one after attempting it.

That would be where FORGETting and recompiling would come in, which ideally is very fast (which is where your original idea of the sort comes in). Compilation on my '02 Forth is not very fast, but in spite of using the long linked list for FIND, I have other more-major time-takers in my '02 Forth, involving receiving and parsing the input stream with a lot of secondaries (which are converted to primitives in my '816 Forth since the '816 is so much more memory-efficient for primitives than the '02 is). Another consideration however is that variables' and arrays' contents won't survive the recompilation unless extra measures are taken. Overall, I don't find all of this to be much of a problem though.

I didn't want to derail this thread by going into more detail. But it is less about recompiling, but rather writing a routine that goes through each word and adjusts the addresses by the length of word that was removed. Only addresses that are above the removed word, need be adjusted.

This should be extremely fast to adjust as the scan through each word only happens once for a simple check of the addresses. At the same time, another simple check can be made to make sure no other words call the removed word. There would not be a need to re-compile each and every word after the removed word which could be a bit more time consuming.

[IamRob]

JimBoyd wrote:

IamRob wrote:

The FORTH I am working with is pretty incomplete. But it is the best one for the Apple so far.

Is this one you are writing? If so, which standard are you following?

Not so much writing, but upgrading and fixing some crashing issues and adopting words from other Forths.

The original ProForth followed the fig Forth standard when I first downloaded it, and so far have adopted words from Transforth, Graforth, 79 Standard and 83 Standard. Since I am using an 8-bit machine, and ProForth is pretty incomplete, I will adopt any word from any of the Standards that allow me to accomplish what I need to do, simply, quickly and efficiently.

The end goal really is to build an efficient, fully functional Forth system that probably will end up being computer dependent, for the Apple II. The Standard is not as important as the functionality or the diversity.

For example, I don't have a CASE statement, so I look at examples from other Forths and adopt the one that makes the most sense to me. The same as when I picked out which Forth to use. GraForth is an STC Forth whereas ProForth is an ITC Forth.

And even though GraForth might be faster, has graphics support and even has a CASE statement, ProForth allows me to be way more diverse with words, and is a lot more complete in such respects as <BUILDS & DOES>, and Vocabularies.

I can transport words from GraForth and other Forths over to ProForth a lot easier than the other way around. It also helps that ProForth is Prodos based where GraForth is DOS 3.3.

[GARTHWILSON]

IamRob wrote:

For example, I don't have a CASE statement, so I look at examples from other Forths and adopt the one that makes the most sense to me.

Do use a real of (the internal compiled by OF), rather than compiling a bunch of inefficient nested IF...ELSE...THENs. If you need ITC source code, I can give you mine, but it'll take me a little time and effort to make it readable and compatible with the forum software.

[JimBoyd]

IamRob wrote:

The end goal really is to build an efficient, fully functional Forth system that probably will end up being computer dependent, for the Apple II. The Standard is not as important as the functionality or the diversity.

In my opinion, the importance of a standard is not so that your Forth can be ported to another machine. It is so that applications written for another Forth can be ported between your Forth and another. Knowing which standard your Forth follows, as well as where it deviates from that standard, will make porting easier.

[IamRob]

JimBoyd wrote:

In my opinion, the importance of a standard is not so that your Forth can be ported to another machine. It is so that applications written for another Forth can be ported between your Forth and another. Knowing which standard your Forth follows, as well as where it deviates from that standard, will make porting easier.

Now I am a confused by the word "standard". Is it if certain words are included in the Forth System that makes the standard? FIG Forth follows the 79 standard, but I have adopted words from the 83 and ANS standards. Does that make my version of FIG an 83 standard? GraForth follows the 78 standard but uses text files to read and write to. FIGForth uses screens. If I adopt the text file way. Does that lower my standard?

If by "between your Forth and another", do you mean on the same computer?

I believe FIGForth has the highest standard as well as words that support the latest Operating System for the Apple II platform. But there are certain words that I would like to port over from some of the older Forths. Most of the words just pertain to the platform I am using and really can't be part of any standard, like the use of expanded memory, graphics or Operating System.


Which brings up a kind-of related question.

There is a version of Transforth II on disk for the Apple II that is floating around, but I am looking for TransForth IIB, which has some upgraded words I would like to Port. Would anyone have seen this version or come across it? The manual is here but have not seen disk images on any of the regular sites.

http://www.apple-iigs.info/doc/fichiers ... Manual.pdf

[JimBoyd]

IamRob wrote:

Now I am a confused by the word "standard". Is it if certain words are included in the Forth System that makes the standard? FIG Forth follows the 79 standard, but I have adopted words from the 83 and ANS standards. Does that make my version of FIG an 83 standard?

Forth's extensibility allows the language to be expanded and it doesn't matter if you get the new words from another standard or think them up yourself. As for following a certain standard such as the Forth-83 standard, the standard has a required word set. These are words that must be in a Forth-83 system for it to claim compliance. Each word in the required word set must also behave according to the standard. For example, EXPECT takes from the stack the address to store a received string and the count ( the maximum number of characters to receive ). EXPECT saves the number of characters actually received in a variable named SPAN. The Forth-83 Standard also specifies a double number wordset, assembler extension word set, system extension word set, and a list of controlled reference words. The words in the controlled reference words may be included ( some or all ), but don't have to be. Any words included from this list must have the standard behaviour for the system to be compliant. There is also a list of uncontrolled reference words. Any words from this list can be included. Such words do not have to have the behaviour specified in the standard, but conformance to the behaviour specified in the standard is advised.
As for adding words from other standards, that's not a problem ( with compliance ) as long as the words don't conflict with the standard you are following. If, for example, you preferred that EXPECT left a count of received characters on the stack, you can not change it to do that while claiming conformance to the Forth-83 standard. The Ansi Standard does have a word that will do that. It is ACCEPT. ACCEPT can be defined on a Forth-83 system as:

Code: Select all

: ACCEPT  ( ADR CNT1 -- CNT2 )
   EXPECT  SPAN @ ;

There is no conformance issue because the Forth-83 Standard does not have a word named ACCEPT.
Another matter that has been addressed on this forum, if you are adding a word to your system and it already has a standard name somewhere, even if it is just a defacto standard, it is best to use that name. For example, on my Forth-83 system, I had the word UNDO . It would discard the parameters of a DO LOOP so one could exit that word from within the DO LOOP . The word UNDO is not in the Forth-83 Standard, nor is its behaviour. There is, however, a word in the Ansi Forth Standard that does the same thing. It is named UNLOOP . Although my system is a Forth-83 system and not an Ansi Forth system, I renamed UNDO to UNLOOP because the name UNLOOP for that behaviour was a kind of defacto standard.

Quote:

GraForth follows the 78 standard but uses text files to read and write to. FIGForth uses screens. If I adopt the text file way. Does that lower my standard?

The words BLOCK and BUFFER are in the required word set so if you were going for Forth-83 compliance your system would be a subset of the Forth-83 standard. I don't think that part will be a big deal as it won't affect portability of applications, unless the application in question has a dependency on BLOCK or BUFFER . Blocks are not just for source code. They can also store binary data.

Quote:

If by "between your Forth and another", do you mean on the same computer?

Not necessarily.

Quote:

The purpose of this standard is to allow transportability of
FORTH-83 Standard Programs in source form among FORTH-83 Standard
Systems. A standard program shall execute equivalently on all
standard systems.

Quote:

I believe FIGForth has the highest standard as well as words that support the latest Operating System for the Apple II platform. But there are certain words that I would like to port over from some of the older Forths.

I don't think FigForth is so much a standard as it is an implementation model and it is one of the older Forths ( older than the Forth-79 Standard).

Quote:

Most of the words just pertain to the platform I am using and really can't be part of any standard, like the use of expanded memory, graphics or Operating System.

All Forths will have parts that are system dependent. One of Forth's strengths is the ability to get at the hardware and exploit your machine's capabilities in whatever way is most efficient for your machine.

[GARTHWILSON]

Forth can be molded into whatever the programmer wants, which is one of the things that strongly attracts us free-thinkers who are resourceful and want the freedom to do things our own way. I suppose it's also something that kind of repels managers, because it makes them feel like they don't have as much control. (It also makes it hard to sell Forth, because a supplier cannot say, "You need to buy our new version because it has <...>" because you'll just say, "Good idea!" and go implement it yourself, as Forth allows you to extend even the compiler.)

Over the years there have been several attempts to kind of pull things together to improve acceptance by producing and updating standards. The major ones I'm aware of, in chronological order, were Fig, '79, '83, ANS '94, and ANS 2012. If you use different ones on different computers, there may be some subtleties that could prove important, like the difference between symmetrical versus floored division. I myself want to have the option to use others' good ideas, without any obligation to implement an entire optional word set for example just because it has a few words you want. My own uses are pretty disconnected from most others' goals, and portability is not as high a priority as making the best use of my hardware. Take my PIC programmer for example, which is run by my home-made workbench computer, in Forth. No other computer is going to have quite the same I/O.

[JimBoyd]

It was not my intent to push the Forth-83 standard. I referenced it because it is the one which I am most familiar. I'm also not advising strict adherence to whatever standard one chooses. The Forth-83 standard states:

Quote:

FORTH's extensibility allows the language to be expanded and
adapted to special needs and different hardware systems. A
programmer or vendor may choose to strictly adhere with the
standard, but the choice to deviate is acknowledged as beneficial
and sometimes necessary.

To make things easier ( to give your Forth a more consistent feel? ) I would advise picking a standard you like, one that seems best suited to your circumstances, as your starting point. As for picking words from other standards, I would try to get most of them from the standard you're using as your starting point. The words PICK and ROLL have changed behavior from Forth-79 to Forth-83, for example. I would advise defining both of them, if you should choose to include both, so their behaviors come from the same standard.
I have deviated from the Forth-83 standard when It suited me. I Think all the variables defined in the standard are user variables. This is great if your Forth is a multitasking Forth with multiple users. Mine is for a Commodore 64 with one user at a time and background tasks so I've limited the number of user variables to as few as I can get by with. Not to mention that my control flow words look more like something from ANSI Forth than Forth-83. As for naming things, if there is a word from one of the standards ( or even common usage ) that matches the behavior of your word, then I'd recommend using that name. If you don't like EXPECT storing the count of characters received in the variable SPAN , but you define it to return that count on the stack, then it would be a good idea to call it ACCEPT, a word from ANSI Forth. If at a later date someone uses your Forth but wants EXPECT , it can be defined as:

Code: Select all

VARIABLE SPAN
: EXPECT  ( ADDR CNT -- )
   ACCEPT  SPAN ! ;

I went with the Forth-83 standard because I liked it best, better than Fig Forth anyway, but I will deviate from the standard when I feel it's in my best interest to do so.

[IamRob]

On the Apple II, the Fig Forth I have follows the Forth 79 standard, so if I say the Fig Forth standard, I was referring to the Forth-79. I don't believe there was any Forth-83 standard ever written for the Apple II. Most of the older Forths follow the 78 standard and Graforth doesn't follow any standard at all, but has some of the best written words and their usage I have seen on any Forth.

I guess I am adopting quite a few words from a standardless Forth. It has the best CASE statement of any Forth and it does what I would like EXPECT to do. It includes the string length before the string and moves it to the string variable and memory set for it. SPAN becomes unnecessary as the string length can be gotten with the use of "string variable name" COUNT.

[dwight]

Over the years, I've learned to deal with differences in Forth's.
I just got done with helping a fellow bring up a PetForth, that is a version of a early AppleForth.
It is quite different than fig Forth. It is a call threaded Forth. Unlike fig, it checks the stack on the usage of every word that changes stack size.
Hello World looks like:

: Hello PRINT !Hello World! CR ;

It could even look like:

: Hello PRINxxx #Hello World# CR ;

So it is quite different then other Forth's.
I run EForth on my STM single board computer I payed under $2 for ( they are that cheap ).
I do most of my code development on my lap top, with emulation if needed. I use Win32Forth. As was mentioned, if I need to match something I create a new word.
Searches are so quick, I no longer worry about it.
I type EMPTY and then reload the file. It is done before I can move my fingers to another key.
Once it is working I move it to the target platform for final test it there.
I don't run anything that is a 2012 standard.
I do it for a hobby so I don't much care what standard I use or how fast it compiles. I do like both FORGET and EMPTY. They both do two different things for me.
I use Forget when I'm interacting with the actual target. I use EMPTY when on my laptop because to reload a source file is instantaneous.
Dwight

[JimBoyd]

IamRob wrote:

I guess I am adopting quite a few words from a standardless Forth. It has the best CASE statement of any Forth and it does what I would like EXPECT to do. It includes the string length before the string and moves it to the string variable and memory set for it. SPAN becomes unnecessary as the string length can be gotten with the use of "string variable name" COUNT.

Just something to think about, EXPECT doesn't have to be limited to receiving 255 characters. EXPECT for my Forth allows receiving much more than that the same way TYPE allows displaying a string longer than 255 bytes. It can be handy if input is redirected to read a sequential file from disk (or some other source) and some of the lines are longer than 255 bytes.