[ prog / sol / mona ]

prog


What is the real lisp standard

1 2020-10-08 05:57

I don't mean lisp-1 (implementation standard) or ansi maclisp (implementation standard) but real standard of the artificial language, anons say, an algebraic language for the manipulation of symbolic expressions, defines the lisp language but this can't be true with the direct implementation details on an ibm 704 and 709 it has and the machine language it defines. It also says "incomplete" or is there no good standard for this and it's sourced like a quasistandard.

2 2020-10-08 07:44 *

ansi maclisp

???

3 2020-10-08 08:20 *

>>2
Joke term for common lisp.

4 2020-10-09 08:20

>>3
What's the joke?

5 2020-10-09 11:16 *

>>4
Common lisp is known for being backwards compatible with maclisp, sound like a simplified retard while saying it for maximum effect. It's like granny calling c# microsoft java but less stupid and stretched.

6 2020-10-10 07:43

http://www.softwarepreservation.org/projects/LISP/book/LISP%201.5%20Programmers%20Manual.pdf

Page 13

7 2020-10-10 08:34

>>6
Fits the question better then sections of the first programming manual and this whitepaper, don't understand why LISP wasn't defined as LISt Processor again.
The LISP 1.5 and 1 programmer manuals are considered LISP-1* and not LISP in the entirety or even parts depending on who you ask. Would of preferred a lambda papers style over this, it really is sourced from multiple sections across different papers spanning across decades.

Flap Trap

8 2020-10-10 09:18

>>7

Lisp is a happy accident. Notice page 13 in the above PDF is written using m-expressions and not s-expressions. Why is that?

9 2020-10-10 11:52

>>8
I'm not so sure anything should be undervalued here to be called an accident, it's not that unstructured and unexplained. Even lower down from what you're referencing this manual describes part of the pure theory of LISP.
I want to say it helps explain how an meta-expression capable LISt Processor 1.5 would go symbolic and be self hosting using evalquote. Further reading slightly answers by saying m-expressions are used in this manual to describe the actual workings of the interpreter and that pure LISP has a universal function written here as an m-expression for interpreting an application written as s-expressions, evalquote, is that function, I'm guessing. Different conclusions can be brought together from the previous papers but I think that's further from what you're saying here.

10 2020-10-10 17:50

>>9

M-expressions are used in the manual to describe evalquote. But evalquote is implemented in Lisp with s-expressions. Why not simply print the s-expression implementation in the manual? And where are m-expressions today?

11 2020-10-11 02:45

>>10
M-expressions aren't limited to explaining evalquote in this manual, they also describe the elementary functions. Elementary functions are used for ultimately implementing evalquote in m-expressions, if that's what you meant by this, m-expression to s-expression separation can be seen as explaining hosting bootstrapping.
The glossary eludes to part of why m-expressions are dropped.

M-expressions cannot be read by the machine at present but must be hand-translated into S-expressions

The machine can either be the literal ibm 7090 or a backplane using a theoretical hardware LISt Processor. This is partly useless for frankenstein harvards that don't have one and a ibm 7090 or LISt Processor that can't read it. A formal language was also required for the advice taker project, m-expressions are considered a functional notation while LISP is considered a formal mathematical language. The manual describes a formal mapping of m-expressions into s-expressions.

where are m-expressions today?

There was a hobby operating system I remember using two layers of languages, the top layer was a mix of m-expressions and asm, the bottom layer was a incomplete dialectic of LISP, common metal kernel and userland software architecture for operating systems. Even if it's considered decrepit in favour of pure s-expressions, it's still used.

12 2020-10-11 03:38

>>11

M-expressions aren't limited to explaining evalquote in this manual

I know. The m-expressions are supposed to be Lisp. The s-expressions are supposed to be an implementation detail.

The glossary eludes to part of why m-expressions are dropped.

Lisp was supposed to be m-expressions compiled to s-expressions. Humans were never supposed to be dealing with s-expressions directly. M-expressions weren't really dropped. They were still included in the manual several years after no one finished the language.

13 2020-10-11 04:01

>>12
I can see the point from the whitepaper but it's bending things really far by the manuals and can be confused with the completed concept of evalquote from the elementals being LISP and *-expressions being insignificant. Like how s-expressions are purely used today.
Thought talker project was what you meant by accident, which is normal but this is an accident like you describe.
Isn't there something else that solidifies m-expressions were meant to be used directly, other than the incomplete whitepaper.

14 2020-10-11 04:37

>>13

Isn't there something else that solidifies m-expressions were meant to be used directly

http://jmc.stanford.edu/articles/lisp/lisp.pdf

Page 7

15 2020-10-11 04:51

>>14
It's much better but still considered notation here.
The programming language that got adopted today from this page is called LISP lists.

LISt Processor lists

16 2020-10-11 05:14 *

>>15

You lost me. No idea what you're looking for. There is no "real standard". The closest thing to the actual original intention of Lisp is m-expressions. The current state of affairs is due to a series of accidents.

17 2020-10-11 05:22

>>16
Real was pushing the terminology but you gave the closest intention, which could be considered the standard. Assorted language codexs aren't called standards but it's the closest thing usually, unless there really is a standard.

18 2020-10-14 04:28

>>1
The only LISP standards of note are Scheme standards
http://www.schemers.org/Documents/Standards/R5RS/

19


VIP:

do not edit these