This is the mail archive of the
kawa@sources.redhat.com
mailing list for the Kawa project.
Re: Using Kawa to port Perl to the JVM
"Bradley M. Kuhn" <bkuhn@ebb.org> writes:
> For example, I would likely need to add types to Compilation class.
>
> Perl's "native" data types are scalar, array, hash and reference, which have
> clearly defined semantics that must be supported. My plan has been to
> implement these data types as Java classes.
>
> Thus, it seems I would have to add:
>
> static public ClassType perlScalarType =
> ClassType.make("gnu.lang.perl.Scalar");
There is no need that these be in Compilation.java. Note they are just
static fields; Compilation is just a convenient (and historical)
place for them. If you have a Perl.java that is a good place for them.
> I have read internals.xml a few times, but it doesn't go to the level of
> depth I'd need to simply begin hacking. Once I figure it out enough, I
> suppose should write a tutorial on porting new languages to Kawa. ;)
>
> Any hints you can give beyond what is in internals.xml, I would appreciate
> it.
Well, one language that is quite different is EcmaScript (JavaScript);
that may give you some insights.
What I suggest: Start by defining classes for the data types (scalar, array,
hash and reference), and the (global) symbols. You need to decide how to
handle the different Perl namespaces: Either similar to how Kawa handles
the two namespaces (value and function) of Emacs Lisp, or (my recommendation,
at least to begin with): Include the prefix chracter in the name, and
use a single symbol table.
My suggestion is to represent Perl references using
gnu.mapping.Binding, Arrays could be gnu.kawa.util.FVector or some
other sub-class of gnu.kawa.util.Sequence. Hashes might
be gnu.mapping.Environment. Subroutines are instances
of gnu.mapping.Procedure. Other types are scalars.
In other words: Start by looking at the data types, and operations.
> The difficult parts are:
>
> * Perl's native data types must be implemented, and they are pretty
> complex. (Must more complex than those of Scheme, for example.)
But they are not that complex. Regexs are complex, but that's
a libary issue.
> * Almost everything function call in libc is a native op-code in Perl.
That is not a difficult part. Just write a static method for each opcode.
(Of course some may not note implementable in pure Java, so either punt
or use a native method.)
Note you don't need (nor perhaps want) a separate class for each method.
Instead, just write a static method for each primitive operation.
You can still create a Procedure for it, if you need it, but I won't go
into that for now.
> If I could get the proverbial "Hello World" in Perl to compile to Kawa, and
> be able to create simple variables and assign them, that might give me some
> idea of where to go from there.
Ok, let's start with:
print "Hello World\n";
That could implemented by doing:
Expression[] args = { new QuoteExp(new FString("Hello World\n")) };
static ClassType typePerl = ClassType.make("gnu.perl.lang.Perl");
static Method print1Method = typePerl.getDeclaredMethod("print", 1);
Expression body = new ApplyExp(print1Method, args);
ModuleExp module = new ModuleExp();
module.body = body;
new Compilation(module, "myclass", "", false);
This is just a sketch, and I've left out stuff, but in principle it isn't
much worse than that. I assume you use the FString class for Perl Strings;
if Perl strings are immutable, maybe you can just use java.lang.String.
Also, I assume gnu.perl is the package where you will put your Perl code,
and you have:
package gnu.perl.lang;
public class Perl {
public static void print(Object arg) { ... }
}
--
--Per Bothner
per@bothner.com http://www.bothner.com/~per/