What is Forth?

[scotws]

An insight I had while talking to Sam about what to do with negative values for ALLOT: One thing that takes getting used to about Forth is that even though there is a standard, it's very rough around the edges and certainly not complete. For instance, if you "negative allot" (release) too much memory, obviously you are going to trash something at some point. The standard (https://forth-standard.org/standard/core/ALLOT) has nothing to say about this, and in fact, where there should be a test for this case, it says

Code: Select all

( MISSING TEST: NEGATIVE ALLOT )

I think there are two main reasons for this. One, there was always some resistance to the idea of standardization, and the ANSI people have kept all kinds of areas where the application gets to do what it thinks best. In other words, the standard is intentionally lose because a strict version would not be tolerated. Two, since there is no traditional lexer and parser, nobody is forced to sit down and create a complete context free grammar and whatnot for the language.

It certainly takes getting used to.

[whartung]

Specifically to the issue with ALLOT, the C Standard cleverly avoids the problem entirely by specifying the size parameter to be of type size_t, which is unsigned.

The specification seems pretty clear:

Quote:

If n is greater than zero, reserve n address units of data space. If n is less than zero, release | n | address units of data space. If n is zero, leave the data-space pointer unchanged.

They also have this caveat (not mentioned in ALLOT):

Quote:

An ambiguous condition exists if deallocated memory contains definitions.

They go into reasonable detail about the behavior of ALLOT and what Contiguous Data Regions are, and their limitations. The "ambiguous condition" mentioned seems to cover a lot of ground as to what happens with over zealous use of negative ALLOT.

[JimBoyd]

[Edit: My post was wildly off topic for the subject 'What is Forth?' and should have been in another thread.]

[JimBoyd]

whartung wrote:

Specifically to the issue with ALLOT, the C Standard cleverly avoids the problem entirely by specifying the size parameter to be of type size_t, which is unsigned.

Any of the Forth standards could have specified that an error condition exists ( with the possibility of ALLOT aborting or, in the new standard, throwing an exception) if the parameter for ALLOT is negative. I don't think any of them did and I'm glad. I have on occasion used a negative value with ALLOT , but then Fleet Forth is a Forth-83 standard Forth.

Quote:

The specification seems pretty clear:

Quote:

If n is greater than zero, reserve n address units of data space. If n is less than zero, release | n | address units of data space. If n is zero, leave the data-space pointer unchanged.

They also have this caveat (not mentioned in ALLOT):

Quote:

An ambiguous condition exists if deallocated memory contains definitions.

They go into reasonable detail about the behavior of ALLOT and what Contiguous Data Regions are, and their limitations. The "ambiguous condition" mentioned seems to cover a lot of ground as to what happens with over zealous use of negative ALLOT.

Like all of the memory manipulation words in Forth ( ! C! CMOVE CMOVE> MOVE for example ) , it is the programmer's responsibility to use ALLOT carefully.

[BruceRMcF]

scotws wrote:

An insight I had while talking to Sam about what to do with negative values for ALLOT: One thing that takes getting used to about Forth is that even though there is a standard, it's very rough around the edges and certainly not complete. For instance, if you "negative allot" (release) too much memory, obviously you are going to trash something at some point. The standard (https://forth-standard.org/standard/core/ALLOT) has nothing to say about this, ...

The thing to bear in mind here is that it is a communication standard, not an implementation standard. It is, indeed, an effort to allow different implementations to communicate.

So how much "negative allotting" you can do in any given implementation is something that the implementation can specify with precision ... but standard source cannot assume as much as a specific implementation assumes, since the point of standard source is to run on different implementations.

One ALLOT might just adjust a codespace pointer, another one might adjust the pointer to the last dictionary entry if you use a negative ALLOT to release space that contained a definition. The first one does not permit unalloting to forget a dictionary entry, the other one may well USE unallotting as the mechanism to release a dictionary entry. But source that respects the restrictions will run correctly on both.

There seem to be a handful of actual rough edges, but much of what looks like being "rough around the edges" is where boundary where different implementations are allowed to do things differently.

[dwight]

I was just looking at Sam's video. I have one suggestion. He did a bunch of return stack fiddling that would be difficult for many to grasp. Much of that section could have been cleaner with a CREATE ... DOES> ... ;
This would have been a little more instructive.
I also find it easier to maintain code when I pass flags. It is not as compact but I prefer to not fiddle too much with the return stack.
His programming style is otherwise quite good and it is clearly readable, even if one does not fully understand what he is doing without knowledge of the language. For a beginner in Forth I'd recommend looking at what he has done with the thought that "I don't fully get what he is doing" but instead look at is as "wow, things seem so malleable, I should try to use experiments and enhancing, as he had done to create a more complex final project". As a beginner, play with Forth for a while, every now and then, go back look at his youtube again. Critique parts of what he is doing and think about different ways of handling problems.
Another critique I have is his redefining of 'open'. Unless one realized that he made completely different effects, later use would require more debugging.
All in all, the code was compact in source so that one could easily follow the structure. There was the complaint about his use of global variables but one was to realize that by using his mark method, he was using a way of enclosing the scope of the global words. It is not how I would have done it. Although, many, including Chuck Moore don't care for vocabularies, I find them quite useful in maintaining scope. They can even be used for a more sane object methods of thinking and containing a complicated project in order.
But to each his own.
Dwight

[GARTHWILSON]

Yesterday (Sat, Mar 13, 2021) the facebook group "Forth2020 Users-Group" had a Zoom meeting with Leo Brodie, the author of "Starting Forth" and "Thinking Forth" which you can watch at https://www.youtube.com/watch?v=--IJEl6HV2k .  At about 1:26:30, one of the participants says that Forth is the future of robots in space, because of its incremental compilation.  He works in this field, and says it's a huge problem if, for example, you have a very slow link to your spacecraft (because it's so many hundreds of millions of miles away and the signal is so weak when it reaches its destination) and you have to feed it some update code in C and you have a quarter of a gigabyte, whereas in Forth you might be able to get away with only a hundred bytes, because it's not necessary to re-compile anything.

Leo said in the meeting that Chuck Moore was not interested in how others did things.  He wanted what worked best for what he needed, solving one problem at a time.  He said you should do whatever you want, which is what Forth is good at.  His quote was "What is the best way to do this for me?"  Free thinkers.  Someone in the video (I don't remember who) said that you don't really program in Forth, but instead use it to write a language that does what you want.

[GARTHWILSON]

As I was getting rid of a collection of Midnight Engineering magazines (and looking again at what's there so I'd keep anything important), I came across this article again from the Mar/Apr '92 issue, so I scanned it and attached it here.  It tells how Chuck Moore, initially as a software consultant, lamented how bad the software tools and development situation was in the 60's, and started developing what eventually became Forth, then, along with Elizabeth Rather, formed Forth, Inc., then later went on to design Forth chips.

Here's a notable excerpt:

• Forth, Inc. had a novel approach to software maintenance.  "We didn't have software maintenance contracts," Chuck notes.  "We taught their programmers how to maintain the software, then cut the strings."  He recalls that most of the programmers they taught ended up enjoying the language, though some had to be dragged "kicking and screaming" to learn Forth.
  
  "After they learned how to use the language, they were delighted with how easy it was to use and what they could do with the language," Chuck says. "The programmers liked Forth because they could do anything they wanted with the language, and their system had much higher performance.  Management like Forth because they got results on-time and on-budget."

And another, from when he made his first Forth processor, ie, a microprocessor whose machine language instructions were Forth primitives:

• "The 1983 Novix chip ran at 8 MIPS; it was the fastest chip in the world, running the fastest language in the world...unbeatable."

I left the ads in since sometimes it's fun to see the products and prices of 30 years ago.

[GARTHWILSON]

larsbrinkhoff wrote:

nyef wrote:

There's probably an opening here for a discussion of metacompilation approaches and techniques, but that should probably be a separate thread if anyone is interested.

I'm very interested.

The member here who seems to be most involved in that is JimBoyd, who has topics on his FleetForth metacompiler for the C64.  He really knows his stuff.

[electricdawn]

Ok, I necro this thread. Feel free to delete my post if you think it isn't appropriate (which it might not be).

Why, for the love of Kernigan/Ritchie did Charles Moore not use C-type string handling? It would've made everything so much easier... Just one parameter to pass, you don't have to constantly check if you've overshot your target, and just one check when you're done.

Boom. Simple.

I SO wish that Forth would use C-type strings. And, yes, that is me being frustrated at PARSE and PARSE-WORD returning string/length on the stack and FIND expecting a counted string. It just really complicates things. Pascal-type strings are really annoying to deal with. And can only be of limited length. I like Pascal. But not its string handling.

There. I hope I haven't slaughtered any sacred cows.

[GARTHWILSON]

electricdawn, I don't know what some forums have against "necro'ing."  Starting a new topic just because the old one is old just clutters the forum with disjointed things that should be kept together.  Continuing on the old one also has the benefit of giving earlier responders an email alert that there's a new post in the topic (when email notifications are working, which they usually aren't).  Projects here often go for years anyway, with life's usual interruptions, and then we get back to the project, and the topic covering it.  If the subject changes, then sure, start a new topic.

Anyway I could go either way on the strings, because both ways have their benefits.  For certain operations like setting up a loop to concatenate or whatever, it can be advantageous to have the lengths up front, rather than having to go out and check every byte looking for a null terminator.

[electricdawn]

Garth, I agree on the topic of necro'ing if it actually adds some value to a thread. Not sure if my post does.

Yeah, I guess I'm just frustrated right now, because I don't know how to proceed with my dilemma (which is, of course, of my own doing). Not sure if I should just use WORD instead of PARSE-WORD, but that... I don't know... isn't WORD going to be deprecated?

And that still wouldn't solve my

Code: Select all

S" 123 DUP" EVALUATE

dilemma. S" leaves an address and length on the stack. FIND doesn't work on that. How can you EVALUATE such a string without copying it somewhere first and adding a length byte to it?

Darn...

[GARTHWILSON]

It is off-topic, and I almost split it off, but I guess I won't worry about it since this topic is on its 10th page and has run its course, so some wandering isn't going to hurt.

[Dr Jefyll]

GARTHWILSON wrote:

It is off-topic, and I almost split it off

I suppose it could be split off (or it could be continued here). But FWIW the subject of strings is already presently under discussion in another thread. Probably the post SamCoVT made yesterday is a good place for anyone reading to pick it up.

-- Jeff