"compile" vs. "tokenize" (was Re: Password Problem)

[Fairlight]

On Tue, Jun 01, 2004 at 05:45:01PM -0400, Kenneth Brody may or may not have
proven themselves an utter git by pronouncing:
> Fairlight wrote:
> > 
> > No offense, but I'll agree to disagree on this one.
> [...]
> 
> No problem.  However...
> 
> What does it take for you to consider it to be a true "compiler"?
> 
> Must it generate native machine code for the system on which the "compiler"
> is being run?  In that case, what about cross compilers, which generate
> executables for some other platform?

I would consider it a true compiler if it generates machine code for either
the current OS or for the target platform of a cross-compile.  Machine code
being the operative words.

> Must the target platform physically exist in the form of hardware?  In

Yes, IMHO.  Hence "machine".  The virtual thing is a case of semantics, but
in reality, that's software, and is hence an interpreter to my way of
thinking.

> that case, what about Pascal?  The original "compilers" generated code
> for a "Pascal virtual machine" (to use today's terminology).  This machine
> didn't physically exist in hardware, but was emulated within a Pascal
> runtime environment.  (Basically, the same as filePro's tok files.)  It
> sounds like you are saying this isn't a true "compiler" since the machine
> was only a virtual machine.
> 
> However, someone then came along an built a computer that would execute
> the Pascal machine code natively in hardware.

I note your use of the word "original". :) I started with Borland Turbo
Pascal 3.0 on and Apple ][e with an Applied Engineering z80+ card, and it
-did- generate standalone machine-code executables that ran under CP/M
using that card--and z80's were not "Pascal-only" chips.

> Did all of those Pascal "not-really-compilers" all of a sudden become
> true "compilers"?  Nothing changed about the "compilers" themselves, yet
> this definition would change them from "not really a compiler" to "a true
> cross-compiler" overnight.

Well, like I said, it comes down to semantics.  At some level you have to
draw the line, as (as I understand it from a layman's PoV) even the
operations built into a chip can be reprogrammed.  Didn't they do that with
the original Pentium's that had the FPU bug?

And no, I don't think that inventing physical hardware as a target platform
to accomodate something that was being done previously in software really
changes the definition or state of the original compiler.  If it's the
equivalent of bytecode compilation, it's not really falling into the
category of truly compiled, in many people's views.  It's not just me, it's
a large part of the field.  Like I said, by your definition, perl itself is
compiled, not interpreted.  The rest of the world begs to differ,
apparently.

Such things are highly esoteric, however.  Personally, I prefer to call
them perl programs.  Others -insist- on "scripts" because they consider it
an interpreted language.  The truth is that it's a half-breed, somewhere
between, as is fP or anything similar.

Heck, you're better off asking Jay his opinion.  I'm sure he has one, and
he has far more experience at this level of esoteria and language design
than I do.  I just code, I don't develop languages, nor do I write
compilers.  I likely couldn't handle the math necessary to do so.  :-/

All I know is that when I see "compiled", my mind is fixed on "machine
code", where the machine is hardware, be it the local target or the target
of a cross-compile--a physical architecture.  That's my PoV.

mark->
-- 
Bring the web-enabling power of OneGate to -your- filePro applications today!

Try the live filePro-based, OneGate-enabled demo at the following URL:
               http://www2.onnik.com/~fairlite/flfssindex.html