Paradigm | functional, non-strict, modular |
---|---|
Designed by | Luke Evans, Bo Ilic (Business Objects) |
First appeared | 2004 |
Typing discipline | static, strong, inferred |
Major implementations | |
Open Quark Framework for Java | |
Dialects | |
-- | |
Influenced by | |
Haskell, Clean, Java | |
Influenced | |
-- |
The Quark Framework (Open Quark) consists of a non-strict functional language and runtime for the Java platform. The framework allows the compilation and evaluation of functional logic on the Java Virtual Machine (JVM), directly or under the control of a regular Java application. The native language (syntax) for the Quark Framework is called CAL. A full range of Java APIs provides the means to invoke the CAL compiler, manipulate workspaces of modules, add metadata and evaluate functional logic. Functional logic is usually dynamically compiled to Java bytecodes and executed directly on the JVM (with some small kernel logic controlling the normal evaluation order). However, an interpreter (G-machine) is also available.
CAL, and the associated tools and APIs forming the Quark Framework, was conceived in 1998 within Seagate Software (later Crystal Decisions, now Business Objects) as a way to enable a common framework for sharing business logic across business intelligence products. A framework was desired that would allow data behaviour to be captured, at all levels of abstraction, and for these components to be composable into the actual data flows that individual products required. In general terms, such a system had to provide a way to express data behaviour declaratively, with universal composition and typing laws. In essence, this places the problem firmly in the domain of functional languages, and the desire to allow machine compositions of functions without incurring increasing efficiency penalties strongly suggested a non-strict evaluation semantic.
As well as the operational requirements, it was envisaged that future application logic would likely be written for a dynamic platform (such as Java or .Net), and therefore it was determined that the Quark Framework should be native to Java (initially) with considerable emphasis on performance and interoperability with application logic written on that platform. In 1999, work began in Crystal's Research Group on an implementation of this framework. Many of the original insights into lazy functional systems were drawn from implementations of Haskell. Early on, Haskell (HUGS, GHC) was even considered as a starting point for the implementation itself, but a number of requirements made this impractical, so it was decided to let the project emerge and evolve freely following its own design criteria. For the first few years of development, the CAL source language itself was not a primary motivator, but the operational semantics were of primary concern. At this time, CAL was merely a convenient script for expressing functions rather than composing them programmatically through Java APIs, or using a graphical language native to a tool called the Gem Cutter, which began to be implemented in mid-2000 as a way to author systems of functions that could be used in applications. From about 2002 onward, the CAL language became rather more central to the Quark Framework, especially once programmers began to create usable libraries of functions for real applications. As the language evolved, so did the demand for tools, and so a range of tools and utilities were created in parallel to language development to support those doing real work with the platform.