It's not very sophisticated, and it's not a BASIC parser.
What it does, though, is provide some nice features:
* Labels. You can write BASIC without line numbers. And it's refreshing.
* Variable labels. You can write as if BASIC 2.0 allowed long variable names. This is similarly refreshing. And my script will complain if you re-declare one. What does this get you? Read on.
* Labels with dots. You can use the period in label names. What does this get you? Read on.
* Variable labels with dots. You can use the period in variable labels. Why?
* Multiple files. You can split your BASIC up into multiple source files.
This is essentially a measure of syntactic sugar. And you still have to be careful.
But.
As long as you're careful, it gets you LOOSE COUPLING and HIGH COHESION with your program segments.
Here's how:
1. Treat each source file as a subsystem. An object, if you prefer. For example, you might have a file named
record.list
which contains data and subroutines for managing "records" in your program.
The rest of your program shouldn't care WHAT those records look like or HOW they're managed. You just need to expose subroutines that manipulate the data in needed ways.... yeah I mean an API.
2. Give each source file its own long variables.
3. Name these variables as if they were fields in structures. For example:
longvar \record.name r0
longvar \record.strength r1
longvar \record.xp r3
4. Encapsulate your longvars with subroutines, using labels as entry points into "methods":
{:record.tostring}
o$ = \record.name$ + ", " + \record.strength + \record.xp
return
Voila. Each file could have its own API, and its labels look like method calls (even though they're not). Again, this is SYNTACTIC SUGAR. What's the big deal? Well suppose you're editing main.list, and you want to manipulate some records. If you define a nice API, you could do it like this:
;
; CONTRIVED EXAMPLE
; (p.s. these are comments that won't show up in the "compiled" BASIC 2.0 file)
; (you can still use REM for preserved comments)
;
\sort.format$ = "asc" :gosub {:records.sort}
gosub {:records.rollup}
gosub {:records.print}
Ever lose your variables? Ever have to write them down in a notebook? Do you STILL have to write them down in a notebook?
NO -- if you're careful!
Question. In the above fragment, where is records data managed? I would guess you put it in the file named "records.list". And where are the subroutines records.sort(), records.rollup(), and records.print()? Same place, I'd say.
And if you did it that way, then you'd find it much easier to:
1. Keep track of your variables
2. Keep track of your subroutines
3. ENCAPSULATE your logic based on your data
It's not foolproof by any means, and it doesn't simulate any nice flow control like while() and for(;;). But... but it does give you a way to break down your code into conceptual pieces, manage your variables, and even provide a form of "trusted" encapsulation. You're free to violate all of this, but the point of the script is to help me manage my code. Maybe it can help you as well. Or inspire you to write something better.
It requires Perl. But then, doesn't every great tool? (Ha!)
basic-labelmaster.pl
