31–40 of 42 posts
[1] https://sarabander.github.io/sicp/html/4_002e1.xhtml#g_t4_00...
Earlier quoted context omitted.
It isn't a LISP :P
You don't need a language to be a LISP in order for them to be able to interpret themselves. There are several Java interpreters which can interpret themselves, for example.
Earlier quoted context omitted.
You don't need a language to be a LISP in order for them to be able to interpret themselves. There are several Java interpreters which can interpret themselves, for example.
Do they interpret java, the programming language, or java bytecode? Not the same thing. lisp being homoiconic, it's much easier to implement a metaciruclar evaluator. https://en.wikipedia.org/wiki/Homoiconicity
You couldn't, so it's an irrelevant internal detail. The function interprets Java source code.
Earlier quoted context omitted.
It isn't a LISP :P
You don't need a language to be a LISP in order for them to be able to interpret themselves. There are several Java interpreters which can interpret themselves, for example.
Earlier quoted context omitted.
You just need it to be a Lisp in order to do it in such a way that you get confused whether you're in the interpreted language or the host one.
Byterun confuses host and interpreter in plenty of places. It uses the host Python for attribute resolution (all code in getters and setters runs on the host), exception handling (which combines with the previous point to make some NameErrors impossible to catch) and even function calls (but all functions are wrapped so that their _call__ switches back to byterun as the interpreter). Because of that confusion, byteru…
Earlier quoted context omitted.
Do they interpret java, the programming language, or java bytecode? Not the same thing. lisp being homoiconic, it's much easier to implement a metaciruclar evaluator. https://en.wikipedia.org/wiki/Homoiconicity
If I gave you a function that accepted Java source code as text and interpreted it, how would you detect that I was first converting it to Java bytecode and then interpreting that bytecode? You couldn't, so it's an irrelevant internal detail. The function interprets Java source code.
> You couldn't, so it's an irrelevant internal detail. The function interprets Java source code.
In a Lisp interpreter the actual source code is Lisp data, not text. One can give the function access to its source code, allow it to inspect it or even to change it - while the interpreter is executing this source code.
In a Lisp interpreter, the code can even modify the source code (we are not talking about the byte-code or machine code) while it is running.
CL-USER 20 > (let ((code (copy-tree '(+ 1 2 bar))))
`(defun foo (bar)
(print ,code)
(unless (eq (first ',code) '-)
(setf (first ',code) '-)
(foo bar))
(values)))
(DEFUN FOO (BAR) (PRINT (+ 1 2 BAR)) (UNLESS (EQ (FIRST (QUOTE (+ 1 2 BAR))) (QUOTE -)) (SETF (FIRST (QUOTE (+ 1 2 BAR))) (QUOTE -)) (FOO BAR)) (VALUES))
CL-USER 21 > (eval *)
FOO
CL-USER 22 > (foo 41)
44
-42
If we now look at the function, we can see that it was indeed changing itself:
CL-USER 23 > (pprint (function-lambda-expression #'foo))
(LAMBDA (BAR)
(DECLARE (SYSTEM::SOURCE-LEVEL #))
(DECLARE (LAMBDA-NAME FOO))
(PRINT (- 1 2 BAR))
(UNLESS (EQ (FIRST '(- 1 2 BAR)) '-) (SETF (FIRST '(- 1 2 BAR)) '-) (FOO BAR))
(VALUES))
The interpreted execution itself allows also different things then the compiled execution. For example if we have a break point, we can see the actual source code currently executed and we can change it while in the break point and then resume execution. Since the interpreter runs the source code, we can also can modify the interpreter to do something else with the source code, while it is executing it - like recording it or tracing it or stepping it.
I understand that interpreter can directly execute the intermediate byte code (giving us portability benefits), but at some point it must convert the byte code into platform independent machine code. Right?
What exactly differentiates an interpreter and a compiler?
Earlier quoted context omitted.
Do they interpret java, the programming language, or java bytecode? Not the same thing. lisp being homoiconic, it's much easier to implement a metaciruclar evaluator. https://en.wikipedia.org/wiki/Homoiconicity
If I gave you a function that accepted Java source code as text and interpreted it, how would you detect that I was first converting it to Java bytecode and then interpreting that bytecode? You couldn't, so it's an irrelevant internal detail. The function interprets Java source code.
A compiler takes code to transform it into another medium: binary executable, code (transpiler), ...
A interpreter takes code to evaluate it.
All the self proclaimed meta circular or "self-hosted" implementations of java that i have seen actually require an external compiler (eg: javac from the JDK). They are in reality implementations of the java virtual machine, not the language; You can't feed java code to them to execute. they are not even self-hosted.
Earlier quoted context omitted.
If I gave you a function that accepted Java source code as text and interpreted it, how would you detect that I was first converting it to Java bytecode and then interpreting that bytecode? You couldn't, so it's an irrelevant internal detail. The function interprets Java source code.
> If I gave you a function that accepted Java source code as text and interpreted it, how would you detect that I was first converting it to Java bytecode and then interpreting that bytecode? > You couldn't, so it's an irrelevant internal detail. The function interprets Java source code. In a Lisp interpreter the actual source code is Lisp data, not text. One can give the function access to its source code, allow it…
Earlier quoted context omitted.
> If I gave you a function that accepted Java source code as text and interpreted it, how would you detect that I was first converting it to Java bytecode and then interpreting that bytecode? > You couldn't, so it's an irrelevant internal detail. The function interprets Java source code. In a Lisp interpreter the actual source code is Lisp data, not text. One can give the function access to its source code, allow it…
Yeah I know about how Lisp works - I have a PhD in metaprogramming using interpreters and meta-circular compilers. I just don't agree it's really materially different.