Re: Philosophical Issues of JPL & perljvm/Jasmin

Li Chen wrote:
> On Fri, 10 Mar 2000, Flynn, Rick wrote:
> 
> > 
> > Can someone please help me understand the aims of JPL versus those of
> > perljvm/Jasmin?  This really is a naive question on my part - just trying to
> > understand where the two efforts are coming from, headed to, and whether
> > they are anticipated to intersect or possibly even combine at some date in
> > the future.  I've poked around on the perl5-porters archives, various
> > READMEs, etc. but still feel somewhat unclear about who is trying to
> > accomplish what via which methods when. 

> I thought it's the same differences between Jacl and Tcljava.Both has to
> be a bridget between the two different language.

Your analogy is good, but only at an extremely high level.  Although perljvm
is much closer to Jacl than it is to Tcljava, they are not completely
symmetrical.  I have commented below on this issue.

> And One of them (perljvm/jacl) has to be rewritten in Java.

It is the case that large parts of perljvm rely on Java classes that are
created to emulate the behavior of the Perl Virtual Machine [I can't coin
"PVM"---that acronym is taken :(].  However, the key component of perljvm,
the part that translates Perl into JVM bytecode, is actually written in
Perl.  Of course, when that JVM bytecode is generated, you'll need to have
the Java class files around to run that bytecode.

Jacl (and Jpython) are actually full implementations in Java of the Tcl and
Python interpreters.  There is *no way* I would want to try this for
Perl---the Perl internals are just too complex (Consider writing a lexer and
parser for Perl in Java!).  Instead, perljvm leverages the perl front-end to
get the parse tree that would be run on the Perl Virtual Machine.  perljvm
walks this parse tree, generating JVM bytecode, which utilize a set of Java
classes that implement equivalents for the key data structures used by the
Perl Virtual Machine.


In other words, there are basically two ways to port a language to the JVM:
(a) write a full interpreter for your language in Java or (b) have another
compiler for your language generate JVM bytecode.

Jacl and Jpython fall into (a).

GNU Ada and Eiffel fall into (b).

perljvm is a hybrid of (a) and (b).  I had wanted perljvm to be much more
(a) than (b), but I have been forced to go down the (b) road more and more
(sometimes due to some annoyances about the JVM, sometimes because the Perl
Virtual Machine is very complex (as virtual machines go, anyway :)).


> Perljvm and Jacl (and Jpython) also has the responsibility of saying
> whether to replicate all sorts of nice and gentle wrappers over Java's JFC
> or give you direct access to them.

I am not clear on what this means, mostly because I don't know what you mean
by the JFC.  By JFC, do you mean the standard Java classes that come with
packages such as Classpath and the JDK?

The JPL gives you fully functional access to Java classes.  It is "wrapped"
access, to some extent, but it still is very direct access.  

perljvm doesn't need to give you access to them to reach its goal.  The goal
of perljvm is to provide a program that takes as input a Perl program and
gives as output Turing-equivalent JVM bytecode.  It would be nice to give
access to Java objects from Perl through perljvm, but it isn't an initial
goal of the project.

(I know Jpython and Jacl have this.  We can have it too---I suppose I am
just saying I probably won't be the one to do it. :) It would be nice, once
perljvm nears completion, if we integrate it with JPL, so that perljvm can
take JPL source as input, as well as vanilla Perl source.)

> Two points for building the wrappers is providing those who are familiar
> with sockets, Tk, mail and whatnot from a scripting language point of view
> with less responsibility to rewrite their scripts, another benefit is
> you'll have access to Java reasources through tie and hash structures
> which helps you to code faster, it will also come with perl like
> documentation--which is quite more helpful than your regular JFC doc
> dumps.

I don't know if I am reading this correctly, but, AFAIK, the JPL has the
features you are describing.  Also, I don't see this as a core feature that
a Perl->JVM compiler *must* provide (as I said, it would be nice).


[On TclJava and JPL]

> You have to know both language either way,

I dunno---I think that people can use JPL only knowing Perl.  You can use
AWT from Perl by instantiating the Java objects as Perl objects.

> but at least you're not trying to pretend that you can fully embed the
> spirit of a scripting language into Java (which is hard to achieve but
> probably still is a worthwhile endeavor).

I don't know if this is a good thing to do, anyway.  I think that Jpython
and Jacl are limited by the fact that they reimplemented the language
completely.  This would be a poor choice for Perl, because the language can
change to easily (A rough consensus on p5p with Larry's blessing is
enough!).  This aspect of the Perl community is a good thing, and
reimplementing perl completely on the JVM would cause a terrible code
divergence that would make such language changes more difficult.

I believe these kind of considerations were a major motivation in Larry's
successful effort to integrate the Microsoft ports of perl with the
canonical perl source.

> On the large system side, there's alot of potential for perljvm or JPL,
> because if you were one of those retard who bit hook, sinker, and bait
> into the Middleware Scam--

I don't think this is a very nice thing to say.  People make technical
choices all the time, and if they turn out not to work, I don't think we
should tease them about it (Personally, I don't have an opinion one way or
the other on the concept of "Middleware").  In addition, I don't think using
the word 'retard' in this context is appropriate.

> People don't maek too much mention of perljvm stage because it seems to be
> in a hush hush stage.

I am not trying to be hush-hush about it---I am very sorry if it came across
that I was.  My main worry is that I don't want people to download it,
thinking its complete.  It's so far from complete that it would probably
frustrate anyone who doesn't already know the JVM pretty well and have a
basic understanding of the perl internals.

If anyone reading this does know these things, or is interested in learning
them, I would love to have help on perljvm.  The perljvm is at a point where
a number of developers can work semi-independently and make useful
contributions.

I don't have a public CVS server up yet (yes, I know about SourceForge, and
I don't know if it is the right choice for this project---I'm happy to
explain why in private email :), but I am willing to work to get folks
access who want it to help (e.g., daily snapshots or some such, for now).

perljvm could use the help!  Join as now and port Perl to the JVM.  :)

> The last post to this mailing list was that someone has volunteered to
> work on it full time, and it's radio silence since then. 

I am busy working on it.  I was putting in full-time on it back in October
through December.  A family issue left me no time in January and most of
February.  I am working on it much more now, but I do have a number of
commitments, and I suffer from the common lack of tuits.  :)

> I personally can't find any websites or download sites for perljvm.

It's on CPAN (albeit under B::JVM::Jasmin)!  Searches on CPAN for "JVM" turn
it up.  (Can any CPAN gurus out there tell me how I can make it so that CPAN
searches for 'perljvm' find B::JVM::Jasmin?)

Plus, you can get from http://www.ebb.org/perljvm!  (BTW, this site turns up as
the eighth hit in a search at http://www.google.com).

If you want regular updates on the software, please subscribe to
[email protected]
(http://lists.ebb.org/mailman/listinfo/perljvm-announce).  I usually Cc
announcements here, too, but may not do so in the future if it doesn't seem
appropriate.

>  I just hope whoever is working on it is having a great deal of fun and
> solving some pressing problems he's having at work (the same way Larry got
> Perl started) while he is at it.

Well, perljvm constitutes my Master's thesis, so perljvm is the problem I am
having at work.  :)

As for fun, it would be more fun with some fellow hackers joining in. :)

> Good luck whoever you are!! :)

Thank you.

-- 
         -  [email protected]  -  Bradley M. Kuhn  -  [email protected]  -
                          http://www.ebb.org/bkuhn

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE4ysm253XjJNtBs4cRAZqHAKCtPuwJ5OeR+vE0FeowkuVzDjnhYwCeLG1x
HwEmwHGptLW4A8Y8H1Z7XSs=
=1rQ9
-----END PGP SIGNATURE-----