A Foundation for Embedded Languages

Abstract

Recent work on embedding object languages into Haskell use "phantom types" (i.e., parameterized types whose parameter does not occur on the right-hand side of the type definition) to ensure that the embedded object-language terms are simply typed. But is it a safe assumption that only simply-typed terms can be represented in Haskell using phantom types? And conversely, can all simply-typed terms be represented in Haskell under the restrictions imposed by phantom types? In this article we investigate the conditions under which these assumptions are true: We show that these questions can be answered affirmatively for an idealized Haskell-like language and discuss to which extent Haskell can be used as a meta-language.

Embedding an interpreted language using higher-order functions and types

“…It might not be clear why an embedded interpreted language could be useful to an application written in ML. After all, languages like ML and Haskell usually have top-level interactive loops, and there are well-studied techniques for expressing embedded-language terms as Haskell terms (Leijen & Meijer, 2000;Rhiger, 2003), so why not just use ML or Haskell? Why have a scripting language?…”

Experience report

“…When dynamic linking is used for the plugging, the plug-in's functions are registered in a global table in the kernel at load-time. Because all functions do not have the same ML type, phantom types (Rhiger 2003) are used in order to dynamically ensure the program's safety (see Section 4.6). Dynamic linking solves two out of three issues of static linking: it ceases to be necessary for the kernel to be aware of the types of all plug-ins' exported functions, and it becomes more convenient to distribute a plug-in separately from Frama-C (in particular a plugin no longer needs to patch the kernel).…”

“…Both dynamic loading and journalization rely on phantom types (Rhiger 2003). Phantom types -parameterized types which employ their type variables for encoding meta-information -are used in both cases to ensure the dynamic safety of function calls which cannot be checked by the OCaml type system.…”

Embedded interpreters

“…Typechecking object programs can thus be regarded as an orthogonal problem, solved by entirely standard methods. (In cases where object programs are less dynamic and the embedding is shallower, techniques such as phantom types (Rhiger, 2003) can leverage the metalanguage type system to reject ill-typed object programs at compile-time. )…”