[Haskell] ANN: Efficient, dynamically compiled, lazy functional semantics on JVM, having tight integration with the Java language

[Luke Evans]

Well, we actually looked at doing just that in 1999.  There are a number of
reasons why we didn't go that route...

1. Java
This was critical to us because it looked like it was becoming a very
important platform for business applications.  We also wanted easy
cross-platform support, and to be able to leverage Java connectivity and
libraries.  We have since experimented with .NET and believe that Quark
could be hosted on this platform too (delegating of course to its own
primitive/core types).  However this hasn't been a focus for us, to date.
2. Dynamic compilation and interaction with the functional subsystem
Our goals required that everything ran fast and that logic could be
assembled piecemeal under application control, from modules defining the
abstractions of a domain language/model for whatever purpose the application
was using Quark.  As you can see in the videos, the Gem Cutter is truly
interactive, with type information being computed on-the-fly and new
functional entities created quickly and smoothly.  Yet the Gem Cutter is not
special in that regard.  Any Java application can discover functional
components (Gems) and snap these together programmatically into logic to
represent something useful that is immediately executable.  This is a
fundamental feature we desired.
3. Simple syntax, appropriate features
The original intention was to not actually focus so much on the syntax of
the language, because we were more interested in the runtime semantics under
control of Java, with programmatic construction of new functional logic.  We
had CAL from the very beginning as a convenient way to define our 'Gems',
but very much had a design principle to keep the language as simple as
possible.  Haskell really has different goals here, because it is catering
to a wide range of requirements and the need for different styles.  It's
also an excellent place to experiment and develop the genre, and benefits
from a rich palette of syntactic forms.  Anyway, as time went on, we
realised the need to develop CAL into a proper "developer's language", so it
grew a somewhat richer syntax and of course this was driven by our
particular priorities and requirements.  For example, because the Quark
framework is motivated by the desire to create reusable business logic, and
because this is frequently record-oriented, a powerful record capability was
a fairly early necessity.  Similarly, our requirements around tight
integration with Java and Java's own data connectivity (and other libraries)
meant that our 'foreign function' interface had to be as simple as possible
(which also makes it reasonably sophisticated when it comes to the compiler
features that really make it work).

In terms of syntax, if we had decided to adopt Haskell from the beginning,
we would almost certainly now still have a language that wasn't truly
Haskell, because of the forces of our primary concerns acting on some quite
fundamental language features.  Of course, we may have had something more
similar in some areas, and therefore more able to compile certain code
without transforming anything, but this is a matter of degrees.  Though
moot, the extensions over a Haskell 98 base that we would have deemed
necessary would also likely have been based on different choices to those
emerging in the intervening time and possibly being considered for adoption
in future standard Haskell.

While I hope the foregoing gives something of a background to our choice,
I'm pleased to offer a document that deals with these issues in a little
more detail.  My colleague, Bo Ilic, has completed a paper entitled "CAL for
Haskell Programmers", which is available here:
http://homepage.mac.com/luke_e/FileSharing13.html.

Lwe


On 9/28/06 5:13 AM, "Paul Hudak" <paul.hudak at yale.edu> wrote:

> I suspect many of us are dying to ask:  Why not just use Haskell?
> 
>     -Paul
> 
> 
> Luke Evans wrote:
>>  Re: [Haskell] ANN: Efficient, dynamically compiled, lazy functional
>> semantics on JVM, having tight integration with the Java language It could be
>> for a subset of Haskell (probably a large one).  Haskell has some features
>> that CAL does not (many just syntactic sugar, some not) ­ we¹re actually
>> working on a short paper to summarise the differences, primarily for people
>> on this list.  Even without a one-to-one correspondence, this might work in
>> many situations where special lower level CAL could be generated in lieu of
>> higher-level Haskell features.  Still, you would probably be able to go a
>> very long way with not much more than straightforward syntax transformations.
>> Of course, use of Haskell libraries would either have to be mapped to CAL
>> ones, or the Haskell library functions converted themselves (with this
>> treatment applied recursively to dependees).
>>  
>> Lwe
>>  
>> On 9/26/06 10:52 PM, "Tomasz Zielonka" <tomasz.zielonka at gmail.com>
>> <mailto:tomasz.zielonka at gmail.com>  wrote:
>>  
>>   
>>> On Tue, Sep 26, 2006 at 09:22:21PM -0700, Luke Evans wrote:
>>>> Here are a few 'highlights' from our feature list:
>>>> - A lazily evaluated, strictly-typed language called CAL, with many
>>>> similarities to Haskell
>>>  
>>> Do you think that CAL would be a good target for a Haskell compiler?
>>> In other words, would it be a good idea to use CAL as an intermediate
>>> language for a Haskell -> Java byte-code compiler?
>>>  
>>> Best regards
>>> Tomasz
>>>  
>>>  
>>  
>