develooper Front page | perl.perl5.porters | Postings from August 2009

Re: p5 on the JVM

Thread Previous | Thread Next
From:
Ben Evans
Date:
August 22, 2009 05:59
Subject:
Re: p5 on the JVM
Message ID:
38a53eb30908220559r3d0b4a04g50b61820ab9dca38@mail.gmail.com
On Sat, Aug 22, 2009 at 1:02 PM, Reini Urban <rurban@x-ray.at> wrote:

> Ben Evans schrieb:
>
> Everybody knows that parsing valid perl5 is not to be done
> again from scratch.


Assuming I've correctly parsed what you've written there - everyone may know
it, but no-one was able to explain why, what language features caused it to
be so, how bad the problem really was and what would have to change to
correct what is, in my view, a very, very serious flaw.

So now, at least we know why it's broke, and the extent to which it really,
really ain't fixable.


> Why didn't you just took the already parsed B optree and convert that to
> .class files?
>
> 2: http://lists.parrot.org/pipermail/parrot-dev/2009-March/001735.html


For about 8 reasons which I can immediately think of. One of which is that
to run on the JVM we'd need a pure-Java-platform solution. Even if the "use
B opcodes" approach was thought of as purely a compiler tool to output
.class files for use elsewhere, string eval is then ruled out, becuase the
.class file representation can't parse a source string.

Also, the same complaint that you make in that post about the pbc format
applies equally to the B modules, as far as I can see - it doesn't seem to
be remotely a stable interface that one could use for serious long-term
development.

Also, given how people here seem to feel about source-level
backwards-compatibility (even as applied to features which are horribly
antiquated, demonstrably broken, very thinly used or outright pathological)
then trying to work with any other level that source seemed to me to be a
bad idea.

Ben

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About