Looks like we have a different way of thinking, not to mention thinking about
a particular idea.

Obviously definitions and distinctions are only for those who care about them,
and everyone else is free to ignore them so that there is no debate.

Although if I'm not mistaken, it seems like we agree (minus perhaps my
misunderstanding of how perl handles begin and end blocks, or bytecode..).


------ Original Message ------
Received: 08:32 AM EST, 12/10/2014
From: Aristotle Pagaltzis <pagalt...@gmx.de>
To: perl6-users@perl.org
Subject: Re: Definitions: compiler vs interpreter [was: Rationale for a VM +
compiler approach instead of an interpreter?]

> * Parrot Raiser <1parr...@gmail.com> [2014-12-07 22:40]:
> > The practical distinction, surely, is that the output of a compiler
> > is usually kept around, to be run one or more times, whereas the an
> > interpreter always works with the original human-readable source.
> Yes, surely that’s it. We all consider Python a compiler, after all.
> :-)
> Go on, tweak your definition to pin it down. :-)
> * Gerard ONeill <oobl...@usa.net> [2014-12-08 15:10]:
> > How about an interpreter interprets input directly into action (even
> > if there is some optimization going on), while a compiler converts
> > instructions from one set to another set to be interpreted later.
> That’s just an unnecessarily concrete rephrasing of the definitions
> I mentioned.
> > Which would make perl both at the perl source level,
> Perl never interprets raw perl code without first parsing it into an
> optree.
> > and an interpreter at the bytecode level.
> Well yeah, bytecode always implies an interpreter.
> > Thinking of execution as interpretation, this allows for the transmeta
> > concept, where the CPU was just an interpreter / just in time compiler
> > that interpreted x86 instructions.
> >
> > Although modern CISC CPU's have a step where the input to the chip was
> > still converted to microcode which was actually what was run.  So
> > a compilation step, and an interpreting step.
> Execution takes a program as input and produces the program’s output as
> output. So it’s interpretation. By definition.
> Sometimes there are dedicated hard-wired circuits that do it, and
> sometimes there are other layers of abstraction around the hard-wired
> circuitry. The layers can be in hardware, and even then at different
> degrees of abstraction (FPGA vs microcode, say), or in software, and
> really what is software and what is hardware depends merely on your
> perspective. There are plenty of coprocessors that internally run code
> which is opaque from the outside; is that software or hardware?
> That’s what I meant by fuzzy ideas. You don’t get anywhere trying to
> nail this pudding to the wall. You only get somewhere if you accept that
> which is which is relative to your point of view and that the difference
> is defined in terms of the output: compilers transform programs to other
> programs and interpreters transform a program into its output. That’s it.
> E.g. if you have something perl running a Perl program then you have the
> CPU interpreting a program (perl) that itself interprets another program
> (the optree), which in turn was compiled from the user Perl program
> earlier on.
> Once you stop trying to artificially force everything into a single
> absolute distinction, the entire debate about which is which vanishes.
> Regards,
> -- 
> Aristotle Pagaltzis // <http://plasmasturm.org/>

Reply via email to