On Fri, May 18, 2001 at 06:29:11PM -0700, Daniel S. Wilkerson wrote:
> Therefore, if it isn't a back-end and it isn't a front-end, what is it?!
Both!
> Can someone say what it is?
OK. Most languages out there are separate from their implementation. For C,
you have an ANSI specification that tells you exactly what C is and how it
works, and then people come along and implement compilers for it. Perl 5, on
the other had, didn't really have a language specification, but it was tied
into the implementation: "Perl is as perl does". What we're trying to do now
for Perl 6, as I understand it, is to make a cleaner separation between the
language and the interpreter. Perl 6 the language is what gets discussed here;
perl6 the interpreter gets discussed over on perl6-internals.
It's true that perl6 the interpreter will be able to read various different
types of input, rather like GCC. (since GCC can also parse and compile C++,
Objective C and, with a little nudging, Fortran) It's also true that as well
as executing bytecode, it'll be able to write various different types of
output, whether bytecode, JVM bytecode, native executables, or whatever.
Again, a bit like GCC, because GCC can be used as a cross-compiler.
But in a sense, what it will be *able* to do isn't really relevant; what's
important is what we ship and call perl 6, and I envisage that to be the
following parts: a parser for Perl 6 the language; an interpreter and runtime
library for Perl 6; plus all the sundry utility things - the regular
expression engine, the variable handling, the IO subsystem, and so on.
I hope that answers the question. :)
--
Grr... don't get me started on Wagner. The man couldn't resolve a
dominant seventh to a tonic with two musical dictionaries open to the
word "resolution", and a copy of anything by Muddy Waters.
- Eric the Read, in the monastery.
