Having line numbers is pretty much essential for BASIC. This, and its half-brother FORTRAN were, after all, the inspiration for Djikstra’s “Goto considered harmful” – GOTO and the (later addition) GOSUBwere what we used before we had procedures and functions, never mind classes and methods.
But Java (and hence Groovy) has no support for goto statements (it is a reserved word in the language though – but presumably to stop someone actually implementing it.) And labelling support, which might offer an alternative, is absolutely minimal and inflexible.
I thought about parsing the BASIC file line by line – code lines could be in an array and a GOTO interpreted as a signal to process the array for a different starting point. But that is not easy – each line is treated as a stand alone script if that way is chosen and so I would have to set up the environment every time (or, maybe, I could get round that with the binding – I will have to explore that).
There is a Scala BASIC DSL that I could study further, but I don’t know any Scala (beyond its apparent C/C++/Java heritage) – but it seems to process the input line by line, certainly it seems to have a line class.
Subroutines ought to be a bit easier – they can be closures I suspect.
Related articles
- Another software death march begins… (cartesianproduct.wordpress.com)
- Some practical uses of goto (ejrh.wordpress.com)
cartesian product ... stuff about computing mostly 
5 responses to “Struggling with line number problem”
It is a little-known fact that the original BASIC implementation was a compiler. That compiler was incremental: each line was compiled into a independent blob of machine code. No line affected what code should be generated for another line.
Some of the odd parts of the language design were there to make incremental compilation easy. For example, the restricted naming of variables allowed the compiler to permanently allocate all possible variables without costing too much core memory (in 1965 core memory was very expensive and limited).
Sinclair BASIC was a mutant (as were many other BASICs). I don’t suspect that it is nearly as easy to incrementally compile Sinclair BASIC.
BTW, continuations were invented to handle gotos in denotational semantics (if I remember correctly).
I think Logo would be a better basis for a DSL and it would not have these stupid problems for you to solve. BASIC has little to recommend it.
If you want a pointlessly tough problem, why not implement some machine language (PDP-8, i8086, i386, or x86-64, in order of increasing difficulty and usefulness)?
Thanks for the comment.
It’s not entirely pointless, honest. A while back I wrote about the Good Olde Days when I could come back from school and write a 30 line BASIC program to emulate the latest problem we had been talking about in Physics or Maths A level classes and bemoaned the level of boilerplate code needed to do that today. So I am building BINSIC in an effort to see if it really does make programming more accessible.
Sinclair BASIC is a mutant, but it’s more like a subset than a superset so there is nothing too horrible. I picked it because I have an original 1981 manual to hand – but I may (if I ever get that far) add in the bits that were “missing” when I typed in the games from “Basic Computer Games” or the listings in the mags from those days.
Writing an assembler starts to look more like writing an emulator for a machine than anything else – but I have wondered about the Z80 on the ZX80/81 as that would allow me to implement the PEEK/POKE/USR commands 🙂
Adrian: I was not saying your project was pointless (I’m not that rude and I don’t actually think that anyway). I was saying implementing BASIC is pointlessly tough. To expand on that: some of the difficult bits are not actually useful for your purpose as I understand it (to make coding accessibly simple).
For example, the line-numbers do two things in BASIC, but do them worse than alternatives, and make it awkward for you to implement. The two things are: the basis for a line-oriented text editor suitable for a typewriter-like terminal, and labels for control flow (goto, gosub).
I don’t know of any web browser that can work with an ASR-33 or ASR-35 (the terminals for which BASIC was designed). And a good thing. They were noisy and slow (110 Baud = 10 characters per second). Everyone is using some GUI that makes fluid and transparent WYSIWYG editing natural. Imagine: cut and paste!
BASIC’s control flow is horrible. More recent BASICs added what we used to call “structured” control flow constructs. Some don’t even support line numbers.
There are a bunch of languages that are as simple as BASIC, simpler to implement, and more suitable for simple programming. I mentioned Logo because I have a soft spot for it. Logo is almost as old as BASIC.
If your goal is actually retro-computing then Sinclair BASIC makes a lot of sense: it’s what you fondly remember.
BTW, I didn’t suggest writing an assembler, I suggested writing a machine-language emulator. Those are different.
BTW 2: I think processingjs.org is interesting as a gateway programming system. Certainly not perfect — perhaps too complicated. You might find it worth looking at.
Thanks again for the comment.
I can assure you that I took no offence at your first comment – after all I called the whole thing a “death march” in an earlier comment 🙂
I understand the point about assembler versus machine code. Back in the day I actually wrote Z80 machine code into the ZX80 (I wrote the assembler out on paper and then translated it into bytes to put into POKE statements) – I was just being intellectually lazy above.
I have sat in front of this computer all night thinking about what I need to do to move this project on but haven’t really got anywhere. But I don’t want to give up just yet.
[…] Struggling with line number problem […]