Functional Languages and Java interoperability
Joe Thurbon
existing project. That project is currently written entirely in Java.
I'm basically a newbie as far as functional languages go, although I've
been lurking here for several months as a part of my getting up-to-speed.
The particular requirements on the functional language that we choose
are a little nebulous, but they at least would include
* easy compilation of the language from within a Java program, (that is,
we would need to be able to ship the functional language's compiler
along with our product, or some equivalent)
* easy to call the newly compiled functional code from within Java
* easy to call existing Java code from within the functional code
In addition to those, we'd have a strong preference for a language which
statically typed. We'd prefer a terse and clean language, so probably
with type inference.
We probably want a language which gives programmatic access to the
'compiled' structure of the functional language, for example to simplify
or rewrite expressions. (This requirement may be born of my inexperience
with functional languages). We'd prefer to have access to Java objects
that represent the expression somewhere along the compilation pipeline.
For example, we'd want to programatically generate expressions for
compilation, without the need to render those expressions to strings
which are then parsed and compiled.
We've had a pretty good look around, and the candidates we think are
best are Scala and Jaskell (and perhaps LambdaVM).
I'd be interested to read about anyone's experience who might have been
down this road before us.
Cheers,
Joe Thurbon
Nils M Holm
> We've had a pretty good look around, and the candidates we think are
> best are Scala and Jaskell (and perhaps LambdaVM).
If Scheme is functional enough for you, you might have a look
at SISC (http://sisc-scheme.org/).
--
Nils M Holm <n m h @ t 3 x . o r g> -- http://t3x.org/nmh/
Joachim Durchholz
> We probably want a language which gives programmatic access to the
> 'compiled' structure of the functional language, for example to simplify
> or rewrite expressions. (This requirement may be born of my inexperience
> with functional languages).
To answer the implicit question whether such a facility is useful to
you, I'd need to know what you expect to use it for.
Regards,
Jo
Joe Thurbon
The most immediate use will be for a variation of genetic programming.
So, we might have the user enter some expressions, and our software
would pre-compile/parse/whatever those expression into theor
corresponding ASTs. Then we could pull apart, modify and recombine the
ASTs, and execute the modified versions.
But perhaps with something like pattern matching, the pulling-apart and
recombining could be done within the language directly. I guess with a
lisp-y language, one could just operate on the s-expressions directly.
(As I said, I'm still getting up to speed here)
Does that help?
Cheers,
Joe
Ingo Menger
> Joachim Durchholz wrote:
> > Joe Thurbon schrieb:
> >> We probably want a language which gives programmatic access to the
> >> 'compiled' structure of the functional language, for example to simplify
> >> or rewrite expressions. (This requirement may be born of my inexperience
> >> with functional languages).
>
> > To answer the implicit question whether such a facility is useful to
> > you, I'd need to know what you expect to use it for.
>
> The most immediate use will be for a variation of genetic programming.
> So, we might have the user enter some expressions, and our software
> would pre-compile/parse/whatever those expression into theor
> corresponding ASTs. Then we could pull apart, modify and recombine the
> ASTs, and execute the modified versions.
I don't want to discourage you, but that won't work that easily
depending on the language.
Since you mentioned Scala and Haskell, AFAIK there will be no such
thing as compiling just an expression. Programs in that languages
consist of a set of definitions that can mutually reference each
other.
So, you'd want to compile a function definition at least.
However, in the case of Haskell (and probably any language that is
like Haskell) lots of code transformations are being made by the
compiler, so there is also not "the" AST of an expression.
For example, the compiler may transform
if a then 5 else 7
to
case a of { True -> 5; _ -> 7; }
or
case a of { False -> 7; True -> 5; }
or vice versa.
So the best Interface to the compiler would be source code in string
form, IMHO, perhaps produced by your own, self manipulating abstract
syntax trees.
Jon Harrop
> The most immediate use will be for a variation of genetic programming.
> So, we might have the user enter some expressions, and our software
> would pre-compile/parse/whatever those expression into theor
> corresponding ASTs. Then we could pull apart, modify and recombine the
> ASTs, and execute the modified versions.
>
> But perhaps with something like pattern matching, the pulling-apart and
> recombining could be done within the language directly. I guess with a
> lisp-y language, one could just operate on the s-expressions directly.
> (As I said, I'm still getting up to speed here)
>
> Does that help?
Yes. What you have described is the idiomatic approach in dynamically typed
programming languages with metacircular evaluators, like Lisp or Scheme.
However, this approach is almost non-existant in modern functional
programming languages like SML, Haskell, OCaml and F#. The idiomatic
approach in these languages is to try to compose statically-typed functions
instead of building ASTs and invoking a compiler. If that does not work
(e.g. if you are trying to write an interpreter for another language) then
you resort to generating abstract syntax trees and writing your own
interpreter to evaluate them.
Saying "one could just operate on the s-expressions directly" is misleading
because s-exprs are Lisp's native sum type. In modern FPLs you would write
down your own sum type, customised for your application.
You might like to look at some of our free articles here:
http://www.ffconsultancy.com/ocaml/benefits/?clf
Particularly the example interpreter.
You may also like the following pages about genetic programming in OCaml:
http://thelackthereof.org/wiki.pl/OGPF
http://www.kenrawlings.com/archives/2004/11/18/gp-linux/
For an introduction to OCaml, read the first chapter of my book on-line:
http://www.ffconsultancy.com/products/ocaml_for_scientists/chapter1.html
HTH.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
bilic
It meets the criteria you listed, including the optional ones. In
fact, CAL was created to address our desire to write applications both
in Java and a modern strongly-typed functional language, and be able
to easily and conveniently ship the resulting product.
CAL was released as open source (BSD) this year by Business Objects,
but it is actually quite a mature language with plenty of
documentation, in development since year 2000. You can compare some
CAL programs on the Shootout benchmarks site as well
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all
There is access via Java to the SourceModel, which is a programmatic
representation of CAL program elements, including expressions. These
can be compiled directly by the CAL compiler, and are not first
converted to text and parsed. There are several applications we have
written internally at Business Objects that make use of this for the
sorts of operations you mention in your subsequent post. There is also
another programmatic model which is higher level, and more
compositional, called the GemGraph. This is used by the Gem Cutter
application, which is a graphical environment for creating CAL
functions. See http://resources.businessobjects.com/labs/cal/gemcutter-techpaper.pdf
or some of the videos or other docs from the main site for an overview
of this.
Cheers,
Bo
Joe Thurbon
> I've been asked to assess some functional languages for use within an
> existing project. That project is currently written entirely in Java.
>
[...]
Thanks to everyone for their replies.
I've followed up on some of the references, and will chase up other over
the coming days.
Of course, if this email were to jog anyone's memory, I'll be lurking so
don't be afraid that you're reply would be ignored.
Cheers, and thanks again,
Joe
Joe Thurbon
> On 18 Okt., 12:29, Joe Thurbon <use...@thurbon.com> wrote:
[...]
>> corresponding ASTs. Then we could pull apart, modify and recombine the
>> ASTs, and execute the modified versions.
>
> I don't want to discourage you, but that won't work that easily
> depending on the language.
> Since you mentioned Scala and Haskell, AFAIK there will be no such
> thing as compiling just an expression. Programs in that languages
> consist of a set of definitions that can mutually reference each
> other.
> So, you'd want to compile a function definition at least.
True, good point.
>
> However, in the case of Haskell (and probably any language that is
> like Haskell) lots of code transformations are being made by the
> compiler, so there is also not "the" AST of an expression.
> For example, the compiler may transform
> if a then 5 else 7
> to
> case a of { True -> 5; _ -> 7; }
> or
> case a of { False -> 7; True -> 5; }
> or vice versa.
>
I wasn't aware of this. Thanks.
> So the best Interface to the compiler would be source code in string
> form, IMHO, perhaps produced by your own, self manipulating abstract
> syntax trees.
>
I think that this seems to be a bit of a theme. Some of the references
Jon suggested across-thread seem to take this approach.
Thanks for taking the time to reply.
Cheers,
Joe