3 ms·
The comments here are interesting, lots of possibilities for other ur-languages. My suggestion is macro based languages. Macro based programming predates all pr
by todd8 3y ago
The comments here are interesting, lots of possibilities for other ur-languages. My suggestion is macro based languages. Macro based programming predates all programming languages other than ASM[1]. The simple macro systems, like early assemblers provided, aren't ur-languages, but once macros can expand other macros and generate definitions of new macros, the macro systems can become general purpose programming systems.
The two earliest macro systems that were clearly designed to be general purpose languages that I know of are Christopher Strachey's GPM[2] and Calvin Mooers TRAC[3] programming language. These languages appeared at roughly the same time, the mid 1960s. I prefer the syntax of TRAC, but otherwise they are almost isomorphic. TRAC was featured in Computer Lib/Dream Machines[4] by Ted Nelson where the author said it was one of the three important languages for programmers to learn. A good introduction to TRAC and it's implementation can be found in Études for Programmers[5].
Other more contemporary examples of macro programming languages are m4, and TeX. LaTeX is programmed in the TeX macro system.
[1] Daniel Weise and Roger Crew, "Programable Syntax Macros", ACM SIGPLAN, 1993, https://dl.acm.org/doi/pdf/10.1145/173262.155105 https://dl.acm.org/doi/pdf/10.1145/173262.155105
[2] Christopher Strachey, “A general purpose macrogenerator,” Computer Journal, 8(3), pp. 225-241, 1965
[3] Calvin Mooers, "TRAC, a procedure-describing language for the reactive typewriter", CACM, Vol 9(3), March 1966, pp. 215-219, https://dl.acm.org/doi/10.1145/365230.365270 https://dl.acm.org/doi/10.1145/365230.365270
[4] Ted Nelson, "Computer Lib/Dream Machines", 1974, Self-published. (There is a 2nd edition from Microsoft Press, but I'm only familiar with the 1st edition).
[5] Charles Wetherell, "Études for Programmers", 1978, Prentice Hall. (It's out of print and available from Amazon for $427. I'm going to have to start locking up my old books.)
- t-3 3y agoMacro/concatenative languages should replace the Forth line. The author is off-base in thinking RPN or stacks are important to Forth rather than concatenativity. RPN is just an easy way to make interpretation simple, an implementation detail, not a functional requirement. It would be like defining APL as being evaluated right-to-left.
- pulvinar 3y agoThe stack is important to Forth, but equally so is its threaded-subroutine-call nature, which isn't present in other early languages that I know of. That puts Forth halfway between assembly and higher-level (and easier to read) languages. I never saw it as a macro language. At least that's the viewpoint I'm familiar with from back when we heavily used it.
- turndown 3y agoWhat do you mean by threaded here?
- mikevin 3y ago> What do you mean by threaded here? Here's a good explanation. https://www.bradrodriguez.com/papers/moving1.htm https://www.bradrodriguez.com/papers/moving1.htm
- jasonwatkinspdx 3y agohttps://en.wikipedia.org/wiki/Threaded_code https://en.wikipedia.org/wiki/Threaded_code It's a way of structuring an interpreter. In forth a word is just a pointer to its definition, which in turn is just a list of pointers to other words, potentially user defined or built in primitives. Execution threads through these pointers, much like making subroutine calls with arguments being passed implicitly on the stack. It's much more compact and lower overhead than a classic interpreter walking a full Abstract Syntax Tree structure. These days most languages are going to a full native code JIT however.
- KingLancelot 3y ago[dead]
- nerpderp82 3y agoThe last two books are available at your favorite site.
- jazzyjackson 3y agoI read about TRAC in Computer Lib while working on a template language that basically just has #! as a special prefix in JSON objects to signal a macro-expansion. I expand macros until there are no more macros to expand, and return that as the result to render in HTML. Reading about TRAC is what made me realize I had a general purpose language on my hands. Too bad, I could have avoided the whole exercise of writing an interpreter, scheduler, debugger if I just left it as an alternative syntax for interpolating variables into HTML. Thanks for the tip on Études for Programmers, looks like I'll be able to look at it in a library at least, surprised archive.org didn't have it.