Given a program P consisting of a linear bit-pattern, that is fed into virtual machine L, and produces a linear bit-pattern B to a section of non-local memory location O.
During the runtime of P on L, the only interaction with non-local memory is writing B to O.
There is no bits passed from non-local memory to local memory.
For all L If and only if L is true to the specification then for any P there is only one possible B.
P is the lisp program source code, which does not read from stdin, keyboard drivers, web sockets or any similar source of external information.
L is a LISP (virtual) machine.
B is some form of data, such as text, binary data, images, etc.
O is some destination could be stdout, screen, speakers, etc.
Ah, ok, I find nothing to disagree with there. Looking back up the conversation, I see that I was responding to the word “behavior”. Specifically, bigjeff5 said:
In other words, the same Lisp code will result in slightly different behavior on a Mac than it would on a Linux machine.
To which you responded:
If Lisp behaves differently from the mathematical ideal on any machine, that means the machine is incapable of supplying said turing machine.
So it comes down to: does the “behaviour” of a Lisp implementation include anything besides the output? Which effectively comes down to what question we’re trying to answer about Lisp, or computation, or etc.
The original question was about whether a Lisp machine needs to include abstractions for the substrate it’s running on. The most direct answer is “No, because the specification doesn’t mention anything about the substrate.” More generally, if a program needs introspection it can do it with quine trickery, or more realistically just use a system call.
Bigjeff5 responded by pointing out that the choice of substrate can determine whether or not the Lisp implementation is useful to anybody. This is of course correct, but this is a separate issue from whether or not the Lisp abstraction needs to include anything about its own substrate; a Lisp can be fast or slow, useful or useless, regardless of whether or not its internal abstractions include a reference to or description of the device it is running on.
Given a program P consisting of a linear bit-pattern, that is fed into virtual machine L, and produces a linear bit-pattern B to a section of non-local memory location O. During the runtime of P on L, the only interaction with non-local memory is writing B to O. There is no bits passed from non-local memory to local memory.
For all L If and only if L is true to the specification then for any P there is only one possible B.
P is the lisp program source code, which does not read from stdin, keyboard drivers, web sockets or any similar source of external information.
L is a LISP (virtual) machine.
B is some form of data, such as text, binary data, images, etc.
O is some destination could be stdout, screen, speakers, etc.
Ah, ok, I find nothing to disagree with there. Looking back up the conversation, I see that I was responding to the word “behavior”. Specifically, bigjeff5 said:
To which you responded:
So it comes down to: does the “behaviour” of a Lisp implementation include anything besides the output? Which effectively comes down to what question we’re trying to answer about Lisp, or computation, or etc.
The original question was about whether a Lisp machine needs to include abstractions for the substrate it’s running on. The most direct answer is “No, because the specification doesn’t mention anything about the substrate.” More generally, if a program needs introspection it can do it with quine trickery, or more realistically just use a system call.
Bigjeff5 responded by pointing out that the choice of substrate can determine whether or not the Lisp implementation is useful to anybody. This is of course correct, but this is a separate issue from whether or not the Lisp abstraction needs to include anything about its own substrate; a Lisp can be fast or slow, useful or useless, regardless of whether or not its internal abstractions include a reference to or description of the device it is running on.