A vision for Parrot

[Ian Bicking]

On Wed, 2002-11-06 at 02:07, Andrew Dalke wrote:
> Frodo Morris wrote:
> > Benjamin Goldberg wrote:
>   ...
> >> What advantage would this have over putting a #! line in the bytecode?
> >>
> > Faster, better, cheaper.
> > Imagine if parrot could understand all interpreted code.  Why not leave 
> > it running, so that any Perl/Python/Tcl/Ruby/Java/sh/BASIC/whatever code 
> > can get to it immediately?
> 
> Some years back, RMS proposed a standard 'scripting' language called
> Guile.  See, various languages like Tcl, Perl, Python, etc. were
> being developed and none of them were 1) developed under the FSF nor
> 2) a variation of Scheme.  (A simplified and perhaps biased
> interpretation of mine.)

I don't think this is really correct -- I think it was mostly because
Tcl was a lame language, and was being pushed as an application
scripting language.  Of course, Lisp is close to RMS's heart, which is
why the FSF proposed Scheme as an alternative over other languages. 
Simplicity was always essential for an application scripting language,
which is probably why Perl wasn't a serious contender.  It was also a
long time ago, when Python was young.  And the translation dream.

> A key part of his proposal was that Guile would support translators
> from other languages, like Python, C, etc., to Guile.
> 
> It didn't happen.  Writing those translators are hard because each
> of the languages has different object models, which must be implemented
> nearly perfectly.  Guile is a full-fledge language built on years of
> research into Lisp and scheme, so I would be surprised if it was any
> easier to implement in Parrot's byte code.  It didn't happen with
> Guile, it's even less likely to happen with Parrot.

Part of the problem with Guile was that there wasn't any developer drive
-- RMS and some others had a vision of translators, but they weren't
involved in developing Guile -- it was mostly Scheme-o-philes, who
unsurprisingly weren't very interested in translators.  The only truly
serious effort was to translate elisp, and even that wasn't really done
in a community manner.

Guile's implementation was also taken from another Scheme
implementation, which was not originally developed with any
consideration to translators.  

But you're right, it is a really hard problem anyway.  And there's lots
of details.  

You have to deal with competing naming conventions -- Scheme allows
almost all characters in its functions, for instance.  Lots of languages
have different namespaces for functions and variables.  Something like
Smalltalk has an entirely different notion of method naming, even though
its semantics are close to these other languages.  It seems small, but
it's a pain.

There's also issues with errors -- if you want a usable language, a
traceback like Python's should be a bare minimum in this day.  But what
does that look like with mixed languages?  What does that even look like
with one language, ontop of a VM that's meant to be generic?  This is
often dealt with very poorly as VM developers mostly test with trivial
and correct programs.

And of course there's a huge number of problems with objects.  Mutable
vs. immutable strings being a good example -- it's not just a n x m
problems, it's a straight-up no-good-solution problem.  There's no
*right* way to deal with this.  Each language means something different
by "string", and yet it's so important to each language that if you
expect them to interoperate *at all* you need to deal with that.  Do you
annotate functions and methods so that some automatic interoperation
layer can be used?  Do you force users to use awkward constructions,
exposing the fact that they're accessing another language?  Do you
create wrappers?  Do you just punt, and assume some simplistic behavior
will be good enough, even though it's not predictable to the programmer?

C#/CLR I believe has resolved these issues by forcing the languages to
adapt to a common set of semantics.  I just can't imagine a common set
of semantics that would bring Perl and Python together -- Python and
Ruby, sure, but there's not enough common ground with Perl to do that.

> I can "imagine if parrot ..."  But it isn't going to happen without
> *huge* amounts of work; comparable to writing Jython.  (A Python
> implementation written on top of Java rather than C.)
> 
> On the other hand, consider the gcc suite of tools.  These convert C,
> C++, Pascal, Fortran, Objective C, ... into a more generic form.  So
> there is some known success in doing this.  But I've looked at gcc
> code and it isn't something I want to hack, while I've contributed code
> to Python's C implementation.

I don't know if GCC has a lot to offer in way of advise or experience. 
It can compile many languages into various instructions, but it doesn't
do anything for interoperability AFAIK (except for deliberately similar
languages, like C and C++, which were built for interoperability).

  Ian