On Mon, Jul 27, 2020 at 11:07:43AM -0700, zeRusski wrote:
>
> >
> > The best way to distinguish compilers from interpreters is that a
> > compiler takes a program and produces another program, whereas an
> > interpreter takes a program (along with some input) and produces an
> > answer.
> >
>
> Doesn't this trivialize the difference a bit too much? Does it really come
> down to the time you choose to compute? I persist intermediate state - I am
> a compiler. I do the exact same thing (run off the same "compiler"
> codebase) but ask for inputs and compute - I am an interpreter.
>
> I scratched my head a bit and came up with the following: if there is one
> to one correspondence between target and host language "blocks" (there may
> be multiple such pairs till you get to machine code) then this is an
> interpreter. If you do nasty shenanigans in the generated code in the host
> (semantics altering optimisation passes and what not) then this is a
> compiler. Latter ought to effect debugging even error reporting quite
> drastically. This is almost certainly naive and amateur of me. I'm
> desperately trying to understand why I have the impression that there ought
> to be a non-trivial difference between the two. That's been my impression
> from the literature.
There is an important distinction here, and it has to do with resource
consumption when iterated.
This is most easily explained in the case(s) of a compiler and
interpreter that are written in the languages they implement.
Clearly you can compile such a compiler using itself, and similarly,
interpret such an interpreter, and you can do that n levels deep should
you want to.
But when going n levels deep, the total execution time with a compiler
is linear in n, and with an interpreter it's exponential.
That makes interpreting interpreters impractical when n gets large (even
with n around 3 or 4); whereas compiling compilers can be done even for
larger n.
This is important when the nesting implemntations are not identical.
This might involve interpreting different languages one in the other.
But it might, very practically, involve compiling different versions of
the same language in a proess of incremental development. The Algol 68
C compiler, for example, went through hundreds of versions, each
compiling the next one, an each providing better tools for the
implementer to use. That would have been practically impossible with a
self-interpreter.
By the way, one of their tests was to use the compiled compiler to
compile itself two levels deep and see if the two self-compiled object
codes were identical. If not, there was a problem.
Many systems are a mix of compiling and interpreting, such as many
Scheme implementations.
And ultimately, the actual machine hardware usually interprets machine
code.
Yes, there are ambiguous corner cases. Such as some of the Apple macs
that run previous hardware generations by compiling basic blocks of
old machine code one by one at run time. Or JIT compilation. Or running
Verilog code on a programmable gate array.
Some of these are situations where the self-implementation model just
doesn't really apply. Silicon is silicon, and is hardware, and isn't
interpreted. It just does what silicon does.
-- hendrik
>
> I think I had this paper in mind: https://www.jilp.org/vol5/v5paper12.pdf
> oh wait p4: "we do not have a precise definition for efficient interpreter"
> ... oh good. Although they do mention some justification for "compiling" to
> a VM in the following paragraphs that boils down to "avoid the overhead of
> re-parsing and re-interpreting intermediate representation". I vaguely
> recall that Lisp in Small Pieces switched to a VM when the "fast
> interpretation" was introduced.
>
> I may have confused myself. Badly :(
>
> I guess I would call Tcl and Picolisp interpreters and Racket and most
> Scheme implementations of note not at all.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/98a4e936-1703-4182-bb85-ce78a8694feao%40googlegroups.com.
--
You received this message because you are subscribed to the Google Groups
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/racket-users/20200728111748.gl7bs2ttcdy7i4oq%40topoi.pooq.com.
