6502.org

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 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.

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: They also have this caveat (not mentioned in ALLOT): 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.

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. 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.

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.

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

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.

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.

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 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...

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