develooper Front page | perl.perl6.internals.api.parser | Postings from December 2000

Re: the mutant beast (was Re: Backtracking through the source)

Thread Previous | Thread Next
Bradley M. Kuhn
December 2, 2000 15:24
Re: the mutant beast (was Re: Backtracking through the source)
Message ID:
Simon Cozens <> wrote:
> On Fri, Dec 01, 2000 at 08:42:57PM -0500, Bradley M. Kuhn wrote:
> > I believe that to do a true port to the JVM (e.g., supporting
> > eval($STRING)), we'll need to implement a bootstrapping parser for the
> > parser code in Java.
> Uhm, and then in every other language we port it to. Are you *sure* that's
> the right approach?

I have looked for another solution, but I can't seem to find one that is any

Depending on how the bootstrapping parser that we write in C is write, it
might be possible to have it generate Java code.  Or, if someone writes a
reliable JVM backend for gcc....

But, these are big if's.  How else can we handle eval($string) on the JVM if
we don't have a parser that runs natively on the JVM?  (Note, for embedded
JVM's, calling back to the C code is likely not an option).

> > My concern is that the more integrated the lexer, parser and tokenizer are
> > integrated, the harder it will be to reimplement in other languages.
> Why? It's just code. I can't understand why porting one big bit of code is
> insurmountably more difficult than porting three slightly smaller bits.

It just seemed that if there were are already existing component modules
modules in a given language, it might be easier to adapt them if the walls
between these components were better.

As I said, these discussions are vague, so I am not sure how it might be
effected; I was just voicing a (possibly unnecessary) concern.

Bradley M. Kuhn  -

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About