6502.org

I know Pascal-type strings... I've worked with Turbo-Pascal way before I learned C in the 80's...
I just think that C-type strings are WAY easier to work with. And are not limited in length. I really do not understand why Charles Moore chose Pascal-type strings over C-type.

I almost mentioned that counted strings were Pascal style. I was in the last Pascal class in high school before they switched to C the following year. C was still busy being invented at the time the original decision was made, so I suppose Pascal-style was the way all the cool kids were doing strings back then.

I don't much like the counted strings and all of the string functions in ANS2012 use ( c-addr u ) type strings (that's character_address and unsigned_length on the data stack). FIND is really the only word I can think of that takes an old counted string (besides COUNT, but it is there to turn old counted strings into the newer ( c-addr u ) type strings. Tali Forth implements a word from Gforth called FIND-NAME that works like FIND but takes the newer style ( c-addr u ) string.

The ( addr u ) type strings do have some distinct advantages:

You don't have to count characters to determine the length. You can immediately use the length in a DO loop. This is technically true with counted strings as well if you don't mind running COUNT on them first.

You can pass string slices around using the data from the original string. By adjusting the address and count on the stack, you can describe a substring in an existing string. You can't easily do this with either counted strings or null terminated strings. It allows for efficient parsing of strings in memory because you can slice them into words without modifying the original string you are parsing from (and FIND-NAME is used here instead of FIND because it can look up names from these strings)

The downside, of course, is the extra stack juggling. Every string needs two items on the stack to describe it.

Forth doesn't have great string handling, but that's very common for languages this old. The youngins these days are used to just reading an entire file into a string variable and then doing things to it.

It seems like FIND is a compatibility carry-over from earlier FORTHs.

PARSE-NAME returns the found word in addr,u style that points into part of the input string, no copying needed.
It is easy to pass addr,u into something like FIND-NAME and the word header compilation word.

I keep forgetting that Forth was invented WAAAY before C was a thing. Or maybe even Pascal. I still think null-terminated strings are easier to work with, but I can see how Charles Moore (probably) used the first thing that came to mind. And that is counted strings.

Dang. Ok, I'll change SLITERAL to add a null-byte to the end of my strings and be done with it. That's easier than rewriting all my calcHASH and srchHASH code.

I may revisit this in the future and add a FIND-NAME of sorts... We shall see.

Thank you for your contributions to this discussion.

Not that far apart. I need to brush up on my history of programming languages.

Yeah, I know. WHEN you need the size. But do you really need it that often? Most of the time you have to crawl up the string anyway to do something with it. I don't know. Anyway. Now all words that produce strings (actually only ACCEPT and SLITERAL if I remember correctly. Actually <# #> doesn't!) produce null-terminated strings, so every word in my Forth that deals with strings is happy.

Here you go: http://james-iry.blogspot.com/2009/05/b ... wrong.html

Thanks, Garth!
And, thanks, BigVerySmartDinosaur! I must apologize to you. I ramble too much. And I actually do things kinda like you in that my SLITERAL actually puts a 16-bit word length "byte" in front of the data string, so I can process longer strings. My dictionary entries are all a mixture of Pascal-type strings (regular length byte) with a terminating null-byte at the end (of course not counted in the string length). All my processes that handle strings look for a terminating null-byte, which allowed me to use a construct like: to implement "tick".

Yes, very much not standard compliant. This is a bit of a mess. And I need to think on how to make this more standard compliant. But not today. Today's Christmas Eve, which - in Germany - is the day to celebrate!

Merry Christmas to all of you.

Edit: Just read the "history" of programming languages and got a good laugh out of it. Thanks, Garth!

Oops -- now that I've read it, I realize it's a spoof... and quite an entertaining one!

But before I read it I remembered I had another item related to the history of programming languages. My intention was to post the item, and FWIW I may as well go ahead (see below).

Forth appears as the blue line that's third from the bottom.

-- Jeff

Oh what a tangled web we’ve weaved with programming languages!

Interesting that your chart has no mention of the progenitor of all computer programming languages.  Also, it completely misses the boat with BASIC, omitting any reference to the two principal timesharing BASIC versions that dominated minicomputers in the 1970s and 1980s, not to mention the various Micro-Soft renditions that shipped with many home computers.

Speaking of timesharing BASIC, I still do some work in Thoroughbred Dictionary IV, which is a powerful, semi-compiled form of BASIC that is capable of highly-structured code, as well as huge database management.  It runs liked a scalded cat on my eight-core, Athlon-powered Linux server.

What? Forth is extinct? And what about my favourite shell: Zsh. It's not even mentioned? Bah! *snort* I shun this report. SHUN it!

To be told this would indeed be cause for high dudgeon! And plainly you're in no small way incensed!

But before you shun the document, you might wanna double-check what it's trying to say...

-- Jeff

I belatedly noticed that there is no mention of PHP in Jeff’s chart.  Millions of interactive web pages have used it.

Well, it says the lineage continues for Postscript, but the black icon of Forth indicates that it is supposed to be dead. >(