LPL(ID:514/lpl001)

List Programming Language 


List Programming Language. LISP-like language with ALGOL-like syntax, for IBM 360.


Related languages
ALGOL 60 => LPL   Derivation of
LISP 1.5 => LPL   Derivation of
LPL => SCRATCHPAD/1   written with

References:
  • Blair, F. W., and Jenks, R. D., "LPL: LISP programming language," IBM Research Report, RC 3062, September 23, 1970. view details
  • Jenks, R. D. "META LISP and META PLUS: Tools for rapidly implementing extendable language translators" view details
          in [ACM] Proceedings of the Second Symposium on Symbolic and Algebraic Manipulation, March 23-25, 1971 Los Angeles (SYMSAM 71) view details
  • Jenks, R. D., "META/PLUS: The syntax extension facility for SCRATCHPAD," view details
          in [ACM] Proceedings of the Second Symposium on Symbolic and Algebraic Manipulation, March 23-25, 1971 Los Angeles (SYMSAM 71) view details
  • Petrick, S. R. "On the use of syntax-based translators for symbolic and algebraic manipulation" view details Extract: META translators
    META translators

    The first class of translators to be discussed is the META family of compilers The prototype of these translators was produced by a Los Angeles SIGPLAN working group on syntax-directed compilers. A number of derivative systems have been produced and used for such purposes as on-line text manipulation, LISP to an intermediate language translation, and translation of the alge- braic language of the SCRATCHPAD System to LISP 1.5. The last of these applications made use of Jenks's META/LISP translator whose notation will be used to provide an example. Consider then the following translator (also due to Jenks) which translates simple arithmetic statement strings into prefixLISPlistforms [...] where the Kleene star is used to denote zero or more occurrences of the parenthesized constituents which it follows. The symbol is used in the usual BNF way to represent alternative expansions of a symbol (i.e., alternative rules).Rules are ordered for parsing purposes and this symbol / implies no "backup" as contrasted with the symbol I which indicates that backup in parsing is to be performed if necessary to obtain ananalysis. The parenthesized strings which are preceded by a + indicate code generation, i.e., translation or semantic specification. A stack, the STAR stack, isused by the system and #1,#2,... denote the first, second,... elements on this stack. The action indicated by #(PLUS#2#1), for example is to destructively read the top two elements of the STAR stack, and then to push on to the topmost position a LISP list whose first  element is the atom PLUS, whose second element is the previous second element of the STAR stack, and whose third element is the previous first element of the  STAR stack.

    The abillty to place code generation strings between the constituents of a phrase structurerule cannot be mimicked by an Irons translator except rather imperfectly through The use of an equivalent grammar. It is obvious, however, that a Knutht ranslator could easily be written to reflect the same sequence of translation steps. (Our formalization, of course, did not allow use of the Kleene starf or phrase structure rule schemata representation.) META/LISP also allows secondary stacks in addition to the STAR stack, and, as we have seen, provides for output structures rather than just strings. This latter property is a particularly useful one for us in many symbol manipulation applications. Both of The-se features are conveniently provided by The Knuth translation program previously described.

    One aspect of the META translators briefly mentioned above is worth expanding.This is that many syntax-directed compilers do not first obtain The structure assigned to a string by a grammar and then proceed to map that structure into a target language equivalent through the use of syntax-based semantic (translation) rules. Instead, in the  process of recognizing an input sentence by implicitly tracing through its structure in some fashion, they call semantic routines which produce actions that ultimately result in the formation of a required  target language output.Even though they do not think of Their algorithms as mapping syntactic structure into target language forms, I find it useful to view their algorithms in this way.

          in [ACM] Proceedings of the Second Symposium on Symbolic and Algebraic Manipulation, March 23-25, 1971 Los Angeles (SYMSAM 71) view details