So, I've been thumping away at parrot's forth implementation, and it's been going pretty well. Bunch of control structures are in (do/loop, do/+loop, begin/again, begin/until, if/then), some horribly insecure stuff has been added (' and compile,), and since Forth can live in its own little world I added in cell space for "address" base storage. In this case "address" and "offset into the cell array" are identical, but that's OK -- the data space, at least according to the standard, doesn't have to correspond to anything else, just be accessible. Which it is.
Unfortunately once the cell space comes in, we get into string issues, since the cell area and strings start getting intertwined.
Forth mandates counted strings. And, at least as far as I can figure, it also assumes that each cell in the cell space can hold a single character. Except... for us, it doesn't have to. I can stuff a whole string into a single cell in cell space, and honestly I'd prefer to do that if I can, and take advantage of our built-in string handling code. (We're already counted, and if I don't have to see someone write a UTF-8 decoder in Forth I think I'd count myself lucky) So I've two alternatives. I can leave Forth as it is, with strings being a series of integer characters with a prepended length word (so the string "Cat" would take up 4 cells) or I can make strings atomic things which'd make integration with parrot much nicer but break the forth standard.
Bah. I should do it both ways, just because...
Posted by Dan at October 28, 2003 04:38 PM | TrackBack (0)Why bother with both ways? Charles Moore is quite fond if reminding you that you should write a programming language that makes *you* more productive. (Alan Kay, John McCarthy and Brad Cox have all said similar things.) Forth worked for Charles in 1970-mumble. Some (including Charles) consider ANSI FORTH to be an abomination on the scale of ANSI Common Lisp.
Is there a benefit to turning 'Cat' into a 4-cell quantity vs. a keeping it a single cell quantity? Sounds like all you'd need are a few more words to twidle characters within a string.
Also, if you don't have any existing Forth code you need to support, why spend time slavishly adhering to a standard that's mostly irrelevant to your purposes?
Posted by: ziggy at October 28, 2003 05:41 PMWhile I don't have any existing Forth code, and I can if I want make this Forth do anything, there is the existing userbase for Forth in general. Yeah, Forth is a flexible language, and Charles is certainly in a position to tell the ANSI folks what they can do with their standard, but I'm still left with the potential of a Forth completely unlike other Forths that are out there for relatively low-level stuff. I'm not sure that I'd really like to pick up a BASIC, say, and find that the string or integer handling's completely different from every other BASIC on the planet. (Atari BASIC did that way back when, and it wasn't the best move they could've made, though I do still remember why and can't fault them)
Having a Forth that only I can use isn't all that useful in general, and that is a big issue. This isn't "Dan's Forth", as I can spell potato, it's Parrot Forth, and I'd prefer it be a relatively standard one, even if just for ad hoc values of standard.
Posted by: Dan at October 28, 2003 08:27 PMI guess you have to stick with the compatibility mode. That is Forth's idea of strings.
Once you work out how to support them natively in Parrot, you can uprgade the string handling code and nothing should break anyway.
Posted by: Yuri at October 29, 2003 12:37 AMThe last time I took a look around the Forth world, I remember seeing a whole plethora of implementations that *mostly* adhered to the ANS Forth spec, adhered with some caveats, or adhered to the spec with some extensions to the spec. Most if not all deviated in one way or another. This was the way it was *supposed* to be -- a simple lightweight language spec that got you close to the "hardware" and let you build the rest of the application from that small core. Portability is not a primary concern; performance and precision are. (On a cloudy day, some pet theory about how code *should* be written in Forth is an even higher priority.)
Taking a look though google, I see that among the recent Forth environments, most claim to be ANS Forth compatible.
Oh well. Looks like that standard isn't all that irrelevant after all.
Posted by: ziggy at October 29, 2003 12:17 PMI had a long series of Atari computers back in the day, and the string array thing always bothered me. When I got a hold of a memory map (and later De Re Atari) I understood that this made for a simpler, smaller implementation.
But still it sucked. Everything had to be thoughtfully ported to AtariBASIC -- you couldn't just re-type and fix the syntax differences.
Design the language that you want, and take suggestions from prior implementations (or from standards).
Posted by: Clinton Pierce at October 30, 2003 01:28 PMHaven't seen the details you are working with, but making the guts be Parrot-like, even if you to make it look like you are doing it Forth-like (cells) at certain places could be a win...
Posted by: Gregor Purdy at November 3, 2003 12:04 AM