Ben Evans wrote: > I've been taking a look at the gnu.expr and gnu.bytecode packages for > possible use as an IR and codegen for a project to investigate compiling > (a subset of) Perl 5 to JVM bytecode.
Cool! > I've had a quick look at the Nice language, which uses gnu.expr and > gnu.bytecode for codegen (and is linked off your pages). > > However, after inspecting the code more closely, it seems that Daniel's > actually basically taken a fork - there are quite a lot of new files > (and some are missing) to support features for Nice, the public methods > are different, etc. I believe his fork is quite old - like from 2001 ... > I was hoping to use a more integrated approach rather than forking - > just use the released kawa jars and add a shim jar, containing any new > classes I need to add to gnu.expr and friends. Yes, that would be much preferable. Though I'm guessing in the short term you'll want to suggest changes/refactoring to Kawa to make it work better for you, so you'll probably want to build from snapshots of the SVN sources. Once you're ready to release, we can make sure there is a compatible Kawa release or at least snapshot available. (Also SVN has some recent goodies, such as Java6 StackMapTable support.) While gnu.bytecode is quite clean and standalone, gnu.expr depends on other packages, mainly gnu.mapping and gnu.text for IO, error handling, and various utilities, and gnu.kawa.reflect for Java (method/field) interop. Plus you may want to make use of gnu.kawa.functions, which handles and optimizes various builtins, such as addition. > I had a couple of questions, if you wouldn't mind: > > 1) Are you aware of anyone else taking this approach? Are there any > languages apart from Nice which use gnu.expr / gnu.bytecode and which > are not distributed with the main Kawa tarballs? The primary other Kawa-based language is BRL. There is a BRL dialect of Kawa in the Kawa sources, but the BRL "mainline" is a separate code-base. However, it's a bit old amd isn't as clean as the BRL dilect in Kawa - which OTOH is incomplete. The author of BRL expressed a plan to migrate to the version in Kawa, but hasn't had time. More interesting to you I think is is XQuery/Qexo or ELisp/JEmacs. Both are in the Kawa source tree, but are relatively cleanly separated: They're in separate packages, and the rest of Kawa doesn't depend on them. > 2) There is currently some discussion about writing a (presumably XML) > serializer / deserializer for gnu.expr to facilitate interop (via > exchange of XML documents describing the IR of compilation units) > between the gnu.expr / gnu.bytecode codegen and a front-end written in > Perl by some other guys (Language::P). The idea is that a Perl-based > frontend may be able to more easily handle some of Perl's ... unique > character ... better than my efforts in a Java parser (and those guys > also potentially want to talk to more backends than just my JVM one). > Has this serialization approach been tried before? Do you think it's a > sensible idea? Would you be interested in looking at the serializer / > deserializer Java classes if they were written? I'm not sure how useful a gnu.expr XML encoding would be - it wouldn't really be useful for other backends. But there is certainly no problem "parsing" an XML encoding of Perl and generation gnu.expr.Expression objects from that. What is the use-case for serializing Expression to XML? I don't know how helpful it is, but in gnu/kawa/xslt is the start of a parser for XSLT, which uses XML syntax. > 3) I am not an experienced compiler writer, so am finding that I am > needing to make additional notes and scraps of javadoc about some of the > classes and methods as I go along. Would you be interested in receiving > this additional javadoc as a patch? Absolutely! I stated a sub-website for gnu.bytecode: http://www.gnu.org/software/kawa/gnu.bytecode/ That is a good place for articles and tutorials. But things that make sense to put in JavaDoc (or source comments) might as well go there! -- --Per Bothner [email protected] http://per.bothner.com/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en -~----------~----~----~----~------~----~------~--~---
