Lisp Interpreter in Tandy TRS-80/100 Basic
m.facebook.com
m.facebook.com
As per your request:
>This one is just for fun. When I first learned Lisp in 1981, I did so by reading Winston and Horn's book and writing my own Lisp interpreter. The interpreter was written in Basic on the only system I had access to at the time: a TRS-80 Model I. This interpreter eventually ended up as part of a series of three articles on Lisp that I wrote for 80 Micro, a TRS-80 hobbyist magazine. The first part of the series, which contains the source code for the interpreter itself, is included here. Note that the listing has all optional spaces removed so that I could fit both the interpreter and 1100 (!) cons cells into 16K (!!) of memory
> There were various Z80 and MOS 6502 microcomputer Lisp implementations written back in the '80s, some commercially released at the time, some readily accessible nowadays. https://www.wisdomandwonder.com/link/3787/how-small-can-a-sc.... https://groups.google.com/forum/#!topic/comp.lang.scheme/Z_2....
> (There's one that I'm horribly, horribly overdue to get back to the authors about archiving on the Internet, actually. Anyone who's based in North America and happens to have the hardware and the expertise to recover data from both 5.25" and 8" floppies in some CP/M format?)
Looks like these are both "business" BASIC variants. Wiki has some information about ProvideX, nothing about BASIS (either the company or the BASIC product). What's the point of coding in these sorts of languages at the dawn of the 2020s? Do you still have a lot of legacy code around that can't be forward-ported for some reason? Do you have non-technical folks surveying the code, or even contributing to it?
Outside of the SV bubble, it's not common for companies to migrate working systems to something new unless the benefits clearly outweigh the costs, and there's nothing better on which those those costs could be spent.
There are a number of stories online, in HN, and in the business press where companies "upgraded" from legacy systems to something "saner" and it ended up costing more time, money, and customers than it was worth.
Both BASIS and ProvideX are based on Java and provide rather thorough JVM integration. The languages themselves also haven't remained stagnant; they have approximate feature parity with Visual Basic. Both are derived from the MAI Basic Four dialect that was popular in the 1970s.
And yes, some large complicated business software, including the MAS 90 and MAS 200 accounting systems, was built using Basic Four. Porting such a complicated code base would be cost-prohibitive compared to porting the Basic Four dialect of Business BASIC to new environments and just running it as is -- so Business BASIC is COBOL-like in that regard also.
The first piece of software I ever wrote and sold commercially was in Business BASIC. It was what we would call a CRM these days, though massively scaled down compared with what we have today. I did it for a limousine company. This was around 1982, IIRC.
I'm aware of this evolution. However, the software at my company was not maintained to keep pace with it. Instead it was endlessly customized within the constraints of the original interpreter. At this point, updating the software to use newer variants even by the same companies would take roughly the same effort as rewriting it in Python, for far less reward.
ProvideX sounds like it's now Sage Group's ERP extension/plugin language. Like SAP's ABAP, Microsoft's "AL", etc.
That's a big question. And how much is that ongoing maintenance going to cost you, when you're critically reliant on it? It's just a single point of failure that will ultimately have to be addressed.
Relying on line numbers, GOTO, GOSUB and RUN/CALL for flow control, all variables are global. This makes it extremely difficult to reason about code and make changes without breaking anything. A modern language would have functions, objects and modules with descriptive names, scoping, and, you know, white space. OH, and it would be stored in a normal text file; the source code for these BASIC interpreters is stored in a binary tokenized format, which makes it difficult or impossible to use version control systems like Git. (I do have something jury-rigged in place for this but it's very ugly.)
Additionally the data is stored in flat files. So a "record" (in this system at least) is basically a really long string with the fields stored in specific places in that string. If you need to change the data structure you have to update the hardcoded substring references in every single program that accesses the file. (Often you are better off defining a new file and cross-referencing it with the others.) There is no relational aspect; what would be a two-line SQL query becomes 40-100 lines of BASIC code where you zip through the whole file record by record, often involving building an intermediate temporary sort file and then zipping through that.
In essence: BASIC, especially this older flavor, is such a "simple" language that using it for anything non-trivial is little better than writing in assembler.
In some BASIC implementations, it was quite possible to 'LOAD' and 'SAVE' programs as plain ASCII text by adding the appropriate incantations somewhere, even though the default representation was tokenized. I'm not sure if the "Business" BASICs you're using can do this.
> Relying on line numbers, GOTO, GOSUB and RUN/CALL for flow control, all variables are global. This makes it extremely difficult to reason about code and make changes without breaking anything.
Well, I'd say less "difficult", and more like "impossible absent a tedious reverse engineering effort". Figure out all the jump targets and all the subroutines, and document the globals that each relies on/modifies. Then you can treat your subroutines as something a bit closer to plain functions. (They'll still be non-reentrant however. Meaning that subroutines cannot recurse in general, not even indirectly.)
> So a "record" (in this system at least) is basically a really long string with the fields stored in specific places in that string. If you need to change the data structure you have to update the hardcoded substring references in every single program that accesses the file.
The really old BASICs had their own notion of "record"-based file that was essentially the only kind of file that could be randomly accessed. "Sequential" files were entirely separate and only supported appending, absent language extensions.
I ended up researching ProvideX pretty heavily as part of that work. The language was evolved from its original roots (much like Microsoft QuickBASIC / PDS evolved out of GWBASIC). Just like QuickBASIC, thought, it could still run the old line-numbered, globally-scoped, nightmare spaghetti code too. There were some neat constructs to deal with ODBC, GUI controls, etc, to be sure, but it seems like it exists now only to serve the old, rickety codebases that are in that "milk the market dry" mode (which pretty much sums up all of Sage's software, too, interestingly enough).
Can walk into shop and purchase magazine and the magazine owner wouldn't know what you read, when you read it.... Equally the outlay would be just for the magazine compared to internet connection, computer capable of browsing the internet and then still have to transfer it to the TRS-80/100.
Then there was the important aspect many miss-out upon today, when you typed something in from a magazine, you got to know the code over just running a program. You made mistakes, and often the magazines would have erata sections to cover typo's from the last edition and with those mistakes - you learned even more than just hitting run.
The Model 100 supports RS232 connections up to (IIRC) 115k baud, but mine gets flaky at that speed, so I keep it at 9600. That's more than fast enough for the tiny files the 100 uses. It's the next door neighbor to instant.
But, apparently, infinitely more resilient!
... on line 4500 looks to be some kind of idiom.. I don't see a corresponding `OPEN` statement?
Compared to the rest of the internet, yes. But for the Model 100 people, this is actually the cream of the crop.
Sadly, information in the Model 100 community is notoriously difficult to get to. Well, not fully "difficult." More like "obnoxious."
Most of the good stuff is on old web sites with many broken links, little documentation, and abysmal navigation. I think the main repository is actually the web site of a guy who died years ago and is kept online, but unmaintained and suffering from severe bitrot, by people about to go the same way.
For interactive discussion, the primary source is a mailing list where people ask the same questions over and over and nobody trims their replies, so you might get a message reply that just says "yep" followed by 150 lines of nested quotes. In digest form, it's simply unusable.
So, amazingly, a Facebook post is a thoroughly modern and convenient way for Model 100 enthusiasts to pass information around, compared to all of the other methods they employ.
As long as the site(s) have been grabbed by Internet Archive, I'm not sure that this has to be an issue. (I've noticed that the archive.org 'Wayback machine' will even archive some downloads, albeit it's not something that should be counted on.)
It doesn't "have to," but sadly it is. The internet, like the rest of the world, is not a perfect place. If IA doesn't find a web site before the bitrot sets in, then what? There are huge swaths of the web that are not in IA, and from what I read on HN, IA doesn't have the capacity to archive.
If you're maintaining some repository of information others find useful, please-please-please have a plan to pass it on to a successor caretaker and a notation in your will about your wishes.
The problem is that we're talking about information that started suffering from bitrot before the Internet Archive became a big thing. Or even before the Internet Archive existed. Heck 99.999% of it existed before the internet.
Sure, it would have been great if on May 13, 1996 someone would have uploaded all of the information that there has ever been about the TRS-80 Model 100 to IA, but that didn't happen.
So often in places like HN the answer to flaws is "Well, you should have...," as if that solves the problem, or makes it go away. But it doesn't. It just makes the person writing that look like a jerk who isn't interested in solving problems, but in pointing out the failings of others.
Part 2 https://archive.org/details/80-microcomputing-magazine-1983-...
Part 3 https://archive.org/details/80-microcomputing-magazine-1983-...
Now to test it out.
I put it also here as per eschaton's request:
Also, I know that ELIZA was available for TRS-DOS (which I think ran on the Z80) and wasn't that based on Lisp?