Contents - Cultural View

Quark Framework 257
Quark Framework
Paradigm functional, non-strict, modular
Appeared in 2004
Designed by Luke Evans, Bo Ilic (Business
Objects)
Typing discipline static, strong, inferred
Major implementations Open Quark Framework for Java [1]
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.
Motivation, History and Concept
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