Content of the Perl6 talk

[Guido van Rossum]

Dan Kuchler <kuchler at ajubasolutions.com> writes:

> If done correctly, only the perl front end would have to be
> implemented, but it would give others the opportunity for trying to
> write some new syntax (which could be like tcl, python, etc.) that
> would work with the existing perl backend.

Lots of interesting pointers in this thread -- wish I had the time to
peruse them all in my copious spare time, but alas I only have until
lunch. :-)

A comment on the hope for a common runtime: I think this will buy you
less than you think.  E.g. you'd expect support for numeric types and
strings to be in the common runtime, right?  Wrong: Python strings are
immutable, Perl strings are mutable; in Python, the number 1 and the
string "1" are totally different things, in Perl and Tcl they both are
the same thing.  And so on for lists (e.g. in Tcl, there's no
difference between a singleton list and its first element, and
Python's the only of the three distinguishing between lists and
tuples), dictionaries (which can have tuples for keys in Python but
not in Perl), and classes/objects.  Not to mention threads, events and
so on.

The best you could hope for would be something at the (much lower)
level of Java bytecode, with extensive language-specific runtime
support for language-specific object semantics.  This is what the
Python translator that Mark Hammond wrote for Microsoft's .NET project
does.

This doesn't save much work for each language implementation, and in
fact slows down each of the language, so I believe the idea is doomed
to failure -- unless there already is an independent reason for having
the common backend, e.g. Java or .NET. :(

--Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)