H ?
«
‹
←
→
›
»
Language peer sets for APLBOL:
United States↑
United States/1975↑
Designed 1975 ↑
1970s languages ↑
Fourth generation↑
High Cold War↑
Genus Array ↑
Specialised Languages ↑
Array↑
Rank 1 unlabelled↑
Rank 1 ↑
Array/1975↑
Rank 1 unlabelled/1975↑
Rank 1/1975↑
Array/United States↑
Rank 1 unlabelled/United States↑
Rank 1/United States↑
Specialised Languages ↑
Specialised Languages/1975↑
Specialised Languages/us ↑
APLBOL(ID:4376/apl011)
APL written in SNOBOL
alternate simple view
Country: United States
Designed 1975
Genus: Array
Sammet category: Specialised Languages
SNOBOL with APL features
Leichter Brandeis 1975
Related languages
| APL |
→
|
APLBOL | |
Subset |
| SNOBOL |
→
|
APLBOL | |
Augmentation of |
References:
Leichter, Jerry. (1976) Leichter, Jerry. 1976. APLBOL. (Unpublished technical report.) Waltham, MA: Brandeis University, Mathematics Department.
Resources
-
Extract: 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().)
Search in:
Google
Google scholar
World Cat
Yahoo
Overture
DBLP
Monash bib
NZ
IEEE
ACM portal
CiteSeer
CSB
ncstrl
jstor
Bookfinder
|