APLBOL(ID:4376/apl011)
APL written in SNOBOL
- Country: us
- Began: 1975
- Type:Array
- Sammet:SPC
SNOBOL with APL features
Leichter Brandeis 1975
Related languages
APL |
=> |
APLBOL | |
Subset |
SNOBOL |
=> |
APLBOL | |
Augmentation of |
References:
Leichter, Jerry. 1976. APLBOL. (Unpublished technical report.) Waltham, MA: Brandeis University, Mathematics Department.
view details
Resources - Newsgroup posting by Jerry Lechter to COMP.LANG.ICON
- Newsgroup posting by Jerry Lechter to COMP.LANG.ICON
It's also possible to write debuggers which allow you to type in SNOBOL code on the fly and evaluate it. I've seen a number of tools of this general sort. I took it to its logical extreme in a system I wrote years ago called APLBOL. APLBOL, which was built on SITBOL on PDP-10's and -20's, had the same user interface as APL, although the language was (of course) SNOBOL. The only "fixed" code in the system was the APLBOL implementation; every line of code a user wrote was actually "established" by CODE(). Worked quite nicely, and it was great for quick and easy development. (Had some amazing hacks in it to make it work, though. Unfortunately, some of the central hacks were based on SITBOL-specific extensions, so it won't work on any other SNOBOL.)
Now, you could argue that APLBOL wasn't SELF-modifying - the APLBOL code modified the user code, not itself, and the user code did NOT modify itself. But that's just the point: Self-modification if uncontrolled is a disaster; but self-modification fit into a rational scheme is extremely useful. (Actu- ally, it WAS possible to modify the APLBOL code, if you knew how and ignored the "don't do this or you may be screwed" rules, which basically reserved a certain name space to internal routines. This could be VERY handy for debugging, but was otherwise not recommended. However, there were a couple of "documented" hooks so that, for example, you could insert a pre-processor that would muck with code before it was handed to CODE().) external link
|