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" <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> >> <mailto:[EMAIL PROTECTED]> 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 >>> >>> >> > _______________________________________________ Haskell mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell
