yeah, i wish i had had the pleasure of meeting him. i reimplemented meta-ii 3½ years ago and would recommend it to anyone who is interested in the parsing problem. it's the most powerful non-turing-complete 'programming language' i've ever used
(i mean i would recommend reimplementing it, not using my reimplementation; it takes a few hours or days)
after i wrote it, the acm made all old papers, including schorre's meta-ii paper, available gratis; they have announced that they also plan to make them open-access, but so far have not. still, this is a boon if you want to do this. the paper is quite readable and is at https://dl.acm.org/doi/10.1145/800257.808896
i think adr is the equivalent of '.long' in gcc or 'dw' in masm, though the description of the adr pseudo-operation is not very clear. it says it 'produces the address which is assigned to the given identifier as a constant'. on a stack/belt machine or an accumulator machine, 'produces' could conceivably mean 'pushes on the stack/belt' or 'overwrites the accumulator with', but the meta ii machine doesn't have an operand stack, belt, or accumulator; it has a return stack with local variables, an input card, an output card, and a success/failure switch, so it doesn't make sense to read 'produces' as a runtime action. moreover, 'adr' is not listed in the 'machine codes' section; it's listed along with 'end' in a separate 'constant and control codes' section, which makes it sound like a pseudo-operation like '.long'. i suspect 'end' tells the assembler to exit
i agree, it would make much more sense to say
'.syntax' .id .out('cll ' *) .out('hlt')
and thus eliminate the otherwise-unused adr, or simply to put the main production of the grammar at the beginning of the grammar, which is what i did in meta5ix. i think they do define 'r' on an empty call stack as a machine halt, btw
they do mention this startup thing a bit in the text of the paper (p. d1.3-3)
> The first thing in any META II machine program is the address of the first instruction. During the initialization for the interpreter, this address is placed into the instruction counter.
so i think the idea is that their 'binary executable format' consists of the address of the entry point, followed by all the code, and the loader looks at the first word to see where to start running the code. this sounds stupid (because why wouldn't you just start running it at the beginning?) but elf, a.out, and pe all have similar features to allow you to set the entry point to somewhere in the middle of the executable code, which means you have total freedom in how you order the object files you're linking. so even though it's maybe unnecessary complexity in this context, it's well-established practice even 60 years later, and maybe it already was at the time, i don't know
i hope this is helpful! also i hope it's correct, but if not i hope it's at least helpful :)
It is a good paper, and I give much respect for ACM opening up their paywall of old papers. They even stopped rate limiting downloads. I'd like to think my incessant whining about this had some effect. :) It is such a wonderful thing for curious people everywhere to be able to read these papers.
thanks! i like lua a lot despite its flaws; that's what i wrote my own literate programming system in. lua's 'bytecode' is actually a wordcode (a compilation approach which i think wirth's euler paper was perhaps the first published example of) and quite similar in some ways to wirth's risc-1/2/3/4/5 hardware architecture family
i hope they do go to open access; these papers are too valuable to be lost to future acm management or bankruptcy
Are you familiar with the 'Leo' editor? It is the one that comes closest to what I consider to be a practically useful literate programming environment. If you haven't looked at it yet I'd love it if you could give it a spin and let me know what you make of it.
i read a little about it many years ago but have never tried it. right now, for all its flaws, jupyter is the closest approximation to the literate-programming ideal i've found
Yes, Jupyter is definitely a contender for the crown, it's a very powerful environment. I've made use of a couple of very impressive notebooks (mostly around the theme of automatic music transcription) and it always gets me how seamlessly the shift between documentation and code is. I wished the Arduino guys would do something like that it would be make their programming environment feel less intrusive and less 'IDE' like (which mostly just gets in the way with endless useless popups).
there are a lot of design decisions that are pretty debatable, but the ones that seem clearly wrong to me are:
- indexing from 1 instead of 0;
- the absence of a nilness/nonexistence distinction (so misspelling a variable or .property silently gives the wrong answer instead of an exception);
- variables being global by default, rather than local by default or requiring an explicit declaration;
- printing tables by default (with %q for example) as identities rather than contents. (you could argue that this is a simplicity thing; lua 5.2 is under 15000 lines of code, which is pretty small for such a full-featured language, barely bigger than original-awk at 6200 lines of c and yacc plus 1500 lines of awk, and smaller than mawk at 16000 lines of c, 1100 lines of yacc, and 700 lines of awk. but a recursive table print function with a depth limit is about 25 lines of code.)
none of these are fatal flaws, but with the benefit of experience they all seem like clear mistakes
It's been long time since I last used lua and only positive memories remained :) I used it for adding scripting in the apps I worked on and the experience was very good -- sandboxed from the start, decent performance.
Perhaps having 0-based indexes would've been bad for our users but I don't think they used arrays at all.
http://www.canonical.org/~kragen/sw/dev3/meta5ixrun.py
(i mean i would recommend reimplementing it, not using my reimplementation; it takes a few hours or days)
after i wrote it, the acm made all old papers, including schorre's meta-ii paper, available gratis; they have announced that they also plan to make them open-access, but so far have not. still, this is a boon if you want to do this. the paper is quite readable and is at https://dl.acm.org/doi/10.1145/800257.808896