oubiwann/jlfe

A wrapper around bits of LFE to make using Erjang (Java) from LFE more convenient

jlfe

An experimental wrapper around bits of LFE

Introduction

This project is 1100100% experimentation.

Its sole purpose is to explore the possibility of slightly increasing programmer convenience when using LFE on Erjang (Erlang on the JVM).

Initially, chunks of LFE code were copied, but the latest version requires that one manually make a single change to a function (instructions below), and then does the rest in the jlfe code.

Development Information

• Goals
• Features

Dependencies

This project assumes that you have lfetool installed somwhere in your $PATH. Also, we're not going to cover the installation of Java -- you will need Java installed on your system in order to run jlfe ;-)

This project depends upon the following, which are saved to ./deps when you run make get-deps:

• LFE (Lisp Flavored Erlang; needed only to compile)
• lfeunit (needed only to run the unit tests)
• lfe-utils

Dependencies not installed automatically:

• lfetool (click the link for installation instructions)
• kerl (see below)
• Erjang (see below)
• rlwrap (readline support for the Erjang shell; installable on many linux distros; on Mac OS X, install with Homebrew)

If you don't have rebar, kerl and Erlang installed:

$ lfetool install rebar
$ lfetool install kerl
$ lfetool install erlang R16B
$ . /opt/erlang/R16B/activate

Erjang installation is similarly easy:

$ lfetool install erjang

Obtaining and Building jlfe

Building jlfe and its dependencies is as easy as this:

$ git clone https://github.com/oubiwann/jlfe.git
$ cd jlfe
$ make compile

That last make target will do the following:

• Download all the project dependencies,
• Apply a patch to LFE to accept the jlfe form (.XXX ...), and
• Compile all the dependencies, the patched LFE, and jlfe.

jlfe Usage

With everything built, you're now ready to play. To run the examples below, start the jlfe REPL:

$ lfetool repl jlfe

Syntax Additions

Constructors

> (.java.util.HashMap)
()
>
> (.java.lang.Double 42)
42.0

Or you can use the short-cut for all java.lang.* classes:

> (.Double 42)
42.0

Static Methods

> (.java.lang.String:getName)
java.lang.String

or

> (.String:getName)
java.lang.String
>
> (.Math:sin 0.5)
0.479425538604203

Static Field Variables

e.g., constants:

> (.Math:PI)
3.141592653589793
>
> (.java.math.BigDecimal:ROUND_CEILING)
2

Nested Classes

> (.java.util.AbstractMap$SimpleEntry "a" "b")
#B()

Utility Functions

Some Java types from Erjang don't render anything useful when evaluated:

> (set bool (.Boolean true))
#B()
> (set flt (.Float 42))
#B()
> (set bigdec (.java.math.BigDecimal 42))
#B()

The value-of function lets us treat Java objects as distinct values while still keeping the object around, should we want to call any methods on it, etc.:

> (jlfe-types:value-of bool)
true
> (jlfe-types:value-of flt)
42.0
> (jlfe-types:value-of bigdec)
42.0

Types that don't need special treatment are passed through, as-is:

> (jlfe-types:value-of (.Integer 42))
42

jlfe's Issues

Rename jlfe_* files to jlfe-*

Now that we're not trying to be part of LFE proper, let's do things the Lisp Way :-)

Convert manual LFE hack to patch

• create a "patches" directory
• move the patch from the README to there
• create jlfe.mk
• add a "patch" make target to jlfe.mk
• update the README to use the new make target

Add support for args in constructors

The following works:

> (set st (call 'java.lang.String 'new '"Apple"))
"Apple"

But not this:

> (set st (.String '"Apple"))
exception error: badfun
  in (: jlfe-java java-call '"Apple")

Get unit tests running

Documentation Request: brief description of benefits of using jlfe

This may be obvious to people within the LFE or Erjang communities, but it's not entirely obvious to me: what benefits would one get from using jlfe?

My guess—and it's only a guess, so I'd love it if the README could confirm or deny this—is that you get

• the infinite flexibility of Lisp as a language,
• the unmatched reliability of Erlang and its actor model, and
• the ubiquity and speed and hardware support of the JVM.

That's definitely some amazing advantages, but is it possible to still maintain the reliability of Erlang without the Beam VM? Are these benefits I mentioned all realistic to expect? Are there others I missed?

Develop a special syntax for instance methods