Abstract
Instead of a monolithic programming language trying to cover all features of interest, some programming systems are designed by combining together simpler languages that cooperate to cover the same feature space. This can improve usability by making each part simpler than the whole, but there is a risk of abstraction leaks from one language to another that would break expectations of the users familiar with only one or some of the involved languages.
We propose a formal specification for what it means for a given language in a multilanguage system to be usable without leaks: it should embed into the multilanguage in a fully abstract way, that is, its contextual equivalence should be unchanged in the larger system.
To demonstrate our proposed design principle and formal specification criterion, we design a multilanguage programming system that combines an MLlike statically typed functional language and another language with linear types and linear state. Our goal is to cover a good part of the expressiveness of languages that mix functional programming and linear state (ownership), at only a fraction of the complexity. We prove that the embedding of ML into the multilanguage system is fully abstract: functional programmers should not fear abstraction leaks. We show examples of combined programs demonstrating inplace memory updates and safe resource handling, and an implementation extending OCaml with our linear language.
Keywords
 Linear Languages
 Multilanguage System
 Full Abstraction
 Intuitionistic Linear Propositional Logic
 Finegrained Composition
These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.
Note: Due to severe space restrictions, many details have been omitted from this presentation of our work. We strongly encourage the reader to consult the complete version at https://arxiv.org/pdf/1707.04984.
Download conference paper PDF
1 Introduction
Feature accretion is a common trend among mature but actively evolving programming languages, including C++, Haskell, Java, OCaml, Python, and Scala. Each new feature strives for generality and expressiveness, and may provide a large usability improvement to users of the particular problem domain or programming style it was designed to empower (e.g., XML documents, asynchronous communication, staged evaluation). But feature creep in generalpurpose languages may also make it harder for programmers to master the language as a whole, degrade the user experience (e.g., leading to more cryptic error messages), require additional work on the part of tooling providers, and lead to fragility in language implementations.
A natural response to increased language complexity is to define subsets of the language designed for a better programming experience. For instance, a subset can be easier to teach (e.g., “Core” ML^{Footnote 1}, Haskell 98 as opposed to GHC Haskell, Scala mastery levels^{Footnote 2}); it can facilitate static analysis or decrease the risk of programming errors, while remaining sufficiently expressive for the target users’ needs (e.g., MISRA C, Spark/Ada); it can enforce a common style within a company; or it can be designed to encourage a transition to deprecate some illbehaved language features (e.g., strict Javascript).
Once a subset has been selected, it may be the case that users write whole programs purely in the subset (possibly using tooling to enforce that property), but programs will commonly rely on other libraries that are not themselves implemented in the same subset of the language. If users stay in the subset while using these libraries, they will only interact with the part of the library whose interface is expressible in the subset. But does the behavior of the library respect the expectations of users who only know the subset? When calling a function from within the subset breaks subset expectations, it is a sign of leaky abstraction.
How should we design languages with useful subsets that manage complexity and avoid abstraction leaks?
We propose to look at this question from a different, but equivalent, angle: instead of designing a single big monolithic language with some nicer subsets, we propose to consider multilanguage programming systems where several smaller programming languages interact together to cover the same feature space. Each language or subcombination of languages is a subset, in the above sense, of the multilanguage, and there is a clear definition of abstraction leaks in terms of user experience: a user who only knows some of the languages of the system should be able to use the multilanguage system, interacting with code written in the other languages, without have their expectations violated. If we write a program in Java and call a function that, internally, is implemented in Scala, there should be no surprises—our experience should be the same as when calling a pure Java function. Similarly, consider the subset of Haskell that does not contain IO (inputoutput as a typetracked effect): the expectations of a user of this language, for instance in terms of valid equational reasoning, should not be violated by adding IO back to the language—in the absence of the abstractionleaking unsafePerformIO.
We propose a formal specification for a “no abstraction leaks” guarantee that can be used as a design criterion to design new multilanguage systems, with graceful interoperation properties. It is based on the formal notion of full abstraction which has previously been used to study the denotational semantics of programming languages (Meyer and Sieber 1988; Milner 1977; Cartwright and Felleisen 1992; Jeffrey and Rathke 2005; Abramsky, Jagadeesan, and Malacaria 2000), and the formal property of compilers (Ahmed and Blume 2008, 2011; Devriese et al. 2016; New et al. 2016; Patrignani et al. 2015), but not for userfacing languages. A compiler C from a source language S to a target language T is fully abstract if, whenever two source terms \(s_1\) and \(s_2\) are indistinguishable in S, their translations \(C(s_1)\) and \(C(s_2)\) are indistinguishable in T. In a multilanguage \(G + E\) formed of a generalpurpose, userfriendly language G and a more advanced language E—one that provides an escape hatch for experts to write code that can’t be implemented in G—we say that E does not leak into G if the embedding of G into the multilanguage \(G + E\) is fully abstract.
To demonstrate that our formal specification is reasonable, we design a novel multilanguage programming system that satisfies it. Our multilanguage combines a generalpurpose functional programming language (unrestricted) of the ML family with an advanced language (linear) with linear types and linear state. It is less convient to program in ’s restrictive type system, but users can write programs in that could not be written in : they can use linear types, locally, to enforce resource usage protocols (typestate), and they can use linear state and the linear ownership discipline to write programs that do inplace update to allocate less memory, yet remain observationally pure.
Consider for example the following mixedlanguage program. The blue fragments are written in the generalpurpose, userfriendly functional language, while the red fragments are written in the linear language. The boundaries and allow switching between languages. The program reads all lines from a file, accumulating them in a list, and concatenating it into a single string when the endoffile (EOF) is reached.
The linear type system ensures that the file handle is properly closed: removing the call would give a type error. On the other hand, only the parts concerned with the resourcehandling logic need to be written in the red linear language; the user can keep all generalpurpose logic (here, how to accumulate lines and what to do with them at the end) in the more convenient generalpurpose blue language—and call this function from a bluelanguage program. Finegrained boundaries allow users to rely on each language’s strength and to use the advanced features only when necessary.
In this example, the filehandle API specifies that the call to , which reads a line, returns the data at type . The latter represents how values of type can be put into a lump type to be passed to the linear world where they are treated as opaque blackboxes that must be passed back to the ML world for consumption. For other examples, such as inplace list manipulation or transient operations on an persistent data structure, we will need a deeper form of interoperability where the linear world creates, dissects or manipulates values. To enable this, our multilanguage supports translation of types from one language to the other, using a type compatibility relation between types and types .
We claim the following contributions:

1.
We propose a formal specification of what it means for advanced language features to be introduced in a (multi)language system without introducing a class of abstraction leaks that break equational reasoning. This specification captures a useful usability property, and we hope it will help us and others design more usable programming languages, much like the formal notion of principal types served to better understand and design type inference systems.

2.
We design a simple linear language, , that supports linear state (Sect. 2). This simple design for linear state is a contribution of its own. A nice property of the language (shared by some other linear languages) is that the code has both an imperative interpretation—with inplace memory update, which provides resource guarantees—and a functional interpretation—which aids program reasoning. The imperative and functional interpretations have different resource usage, but the same input/output behavior.

3.
We present a multilanguage programming system combining a core ML language, ( for Unrestricted, as opposed to Linear) with and prove that the embedding of the ML language in is fully abstract (Sect. 3). Moreover, the multilanguage is designed to ensure that our full abstraction result is stable under extension of the embedded ML language .
2 The and Languages
The unrestricted language is a runofthemill idealized ML language with functions, pairs, sums, isorecursive types and polymorphism. It is presented in its explicitly typed form—we will not discuss type inference in this work. The full syntax is described in Fig. 1, and the typing rules in Fig. 2. The dynamic semantics is completely standard. Having binary sums, binary products and isorecursive types lets us express algebraic datatypes in the usual way.
The novelty lies in the linear language , which we present in several steps. As is common in \(\lambda \)calculi with references, the smallstep operational semantics is given for a language that is not exactly the surface language in which programs are written, because memory allocation returns locations that are not in the grammar of surface terms. Reductions are defined on configurations, a local store paired with a term in a slightly larger internal language. We have two type systems, a type system on surface terms, that does not mention locations and stores—which is the one a programmer needs to know—and a type system on configurations, which contains enough static information to reason about the dynamics of our language and prove subject reduction. Again, this follows the standard structure of syntactic soundness proofs for languages with a mutable store.
2.1 The Core of
Figure 3 presents the surface syntax of our linear language . For the syntactic categories of types , and expressions , the last line contains the constructions related to the linear store that we only discuss in Sect. 2.2.
In technical terms, our linear type system is exactly propositional intuitionistic linear logic, extended with isorecursive types. For simplicity and because we did not need them, our current system also does not have polymorphism or additive/lazy pairs . Additive pairs would be a trivial addition, but polymorphism would require more work when we define the multilanguage semantics in Sect. 3.
In less technical terms, our type system can enforce that values be used linearly, meaning that they cannot be duplicated or erased, they have to be deconstructed exactly once. Only some types have this linearity restriction; others allow duplication and sharing of values at will. We can think of linear values as resources to be spent wisely; for any linear value somewhere in a term, there can be only one way to access this value, so we can interpret the language as enforcing an ownership discipline where whoever points to a linear value owns it.
In particular, linear functions of type must be called exactly once, and their results must in turn be consumed – they can safely capture linear resources. On the other hand, the nonlinear, duplicable values are those at types of the form — the exponential modality of linear logic. If the term has duplicable type , then the term has type : this creates a local copy of the value that is uniquelyowned by its receiver and must be consumed linearily.
This resourceusage discipline is enforced by the surface typing rules of , presented in Fig. 4. They are exactly the standard (twosided) logical rules of intuitionistic linear logic, annotated with program terms. The nonduplicability of linear values is enforced by the way contexts are merged by the inference rules: if is typechecked in the context and in , then the linear pair is only valid in the combined context . The operation is partial; this combined context is defined only if the variables shared by and are duplicable—their type is of the form . In other words, a variable at a nonduplicable type in cannot possibly appear in both and : it must appear exactly once^{Footnote 3}.
The expression takes a term at some type and creates a “shared” term, whose value will be duplicable. Its typing rule uses a context of the form , which is defined as the pointwise application of the connectives to all the types in . In other words, the context of this rule must only have duplicable types: a term can only be made duplicable if it does not depend on linear resources from the context. Otherwise, duplicating the shared value could break the uniqueownership discipline on these linear resources.
Finally, the linear isomorphism notation for and in Fig. 4 defines them as primitive functions, at the given linear function type, in the empty context – using them does not consume resources. This notation also means that, operationally, these two operations shall be inverses of each other. The rules for the linear store type and are described in Sect. 2.2.
2.2 Linear Memory in
The surface typing rules for the linear store are given at the end of Fig. 4. The linear type represents a memory location that holds a value of type . The type represents a location that has been allocated, but does not currently hold a value. The primitive operations to act on this type are given as linear isomorphisms: allocates, turning a unit value into an empty location; conversely, reclaims an empty location. Putting a value into the location and taking it out are expressed by and , which convert between a pair of an empty location and a value, of type , and a full location, of type .
For example, the following program takes a full reference and a value, and swaps the value with the content of the reference:
The programming style following from this presentation of linear memory is functional, or applicative, rather than imperative. Rather than insisting on the mutability of references—which is allowed by the linear discipline—we may think of the type as representing the indirection through the heap that is implicit in functional programs. In a sense, we are not writing imperative programs with a mutable store, but rather making explicit the allocations and dereferences happening in higherlevel purely functional language. In this view, empty cells allow memory reuse.
This view that represents indirection through the memory suggests we can encode lists of values of type by the type . The placement of the box inside the sum mirrors the fact that empty list is represented as an immediate value in functional languages. From this type definition, one can write an inplace reverse function on lists of as follows:
Our linear language is a formal language that is not terribly convenient to program directly. We will not present a full surface language in this work, but one could easily define syntactic sugar to write the exact same function as follows:
One can read this function as the usual functional rev_append function on lists, annotated with memory reuse information: if we assume we are the unique owner of the input list and won’t need it anymore, we can reuse the memory of its cons cells (given in this example the name ) to store the reversed list. On the other hand, if you read the and as imperative operations, this code expresses the usual imperative pointerreversal algorithm.
This double view of linear state occurs in other programming systems with linear state. It was recently emphasized in O’Connor et al. (2016), where the functional point of view is seen as easing formal verification, while the imperative view is used as a compilation technique to produce efficient C code from linear programs.
2.3 Internal Syntax and Typing
To give a dynamic semantics for and prove it sound, we need to extend the language with explicit stores and store locations. Indeed, the allocating term should reduce to a “fresh location” allocated in some store , and neither are part of the surfacelanguage syntax. The corresponding internal typing judgment is more complex, but note that users do not need to know about it to reason about correctness of surface programs. The internal typing is essential for the soundness proof, but also useful for defining the multilanguage semantics in Sect. 3.
We work with configurations , which are pairs of a store and a term . Our internal typing judgment checks configurations, not just terms, and relies not only on a typing context for variables but also on a store typing , which maps the locations of the configuration to typing assumptions.
Unfortunately, due to space limits, we will not present this part of the type system – which is not directly exposed to users of the language. See some examples of reduction rules in Fig. 5, and the long version of this work.
2.4 Reduction of Internal Terms
In the long version of this work we give a reduction relation between linear configurations and prove a subject reduction result.
Theorem 1
(Subject reduction for ). If and , then there exists a (unique) such that .
3 Multilanguage Semantics
To formally define our multilanguage semantics we create a combined language which lets us compose term fragments from both and together, and we give an operational semantics to this combined language. Interoperability is enabled by specifying how to transport values across the language boundaries.
Multilanguage systems in the wild are not defined in this way: both languages are given a semantics, by interpretation or compilation, in terms of a shared lowerlevel language (C, assembly, the JVM or CLR bytecode, or Racket’s core forms), and the two languages are combined at that level. Our formal multilanguage description can be seen as a model of such combinations, that gives a specification of the expected observable behavior of this language combination.
Another difference from multilanguages in the wild is our use of very finegrained language boundaries: a term written in one language can have its subterms written in the other, provided the typechecking rules allow it. Most multilanguage systems, typically using Foreign Function Interfaces, offer coarsergrained composition at the level of compilation units. Finegrained composition of existing languages, as done in the Eco project (Barrett et al. 2016), is difficult because of semantic mismatches. In the full version of this work we demonstrate that finegrained composition is a rewarding language design, enabling new programming patterns.
3.1 Lump Type and Language Boundaries
The core components the multilanguage semantics are shown Fig. 6—the communication of values from one language to the other will be described in the next section. The multilanguage has two distinct syntactic categories of types, values, and expressions: those that come from and those that come from . Contexts, on the other hand, are mixed, and can have variables of both sorts. For a mixed context , the notation only applies to its linear variables.
The typing rules of and are imported into our multilanguage system, working on those two separate categories of program. They need to be extended to handle mixed contexts instead of their original contexts and . In the linear case, the rules look exactly the same. In the ML case, the typing rules implicitly duplicate all the variables in the context. It would be unsound to extend them to arbitrary linear variables, so they use a duplicable context .
To build interesting multilanguage programs, we need a way to insert a fragment coming from a language into a term written in another. This is done using language boundaries, two new term formers and that inject an ML term into the syntactic category of linear terms, and a linear configuration into the syntactic category of ML terms.
Of course, we need new typing rules for these termlevel constructions, clarifying when it is valid to send a value from into and vice versa. It would be incorrect to allow sending any type from one language into the other—for instance, by adding the counterpart of our language boundaries in the syntax of types—since values of linear types must be uniquely owned so they cannot possibly be sent to the ML side as the ML type system cannot enforce unique ownership.
On the other hand, any ML value could safely be sent to the linear world. For closed types, we could provide a corresponding linear type ( maps to , etc.), but an ML value may also be typed by an abstract type variable , in which case we can’t know what the linear counterpart should be. Instead of trying to provide translations, we will send any ML type to the lump type , which embeds ML types into linear types. A lump is a blackbox, not a type translation: the linear language does not assume anything about the behavior of its values—the values of are of the form , where is an ML value that the linear world cannot use. More precisely, we only propagate the information that ML values are all duplicable by sending to .
The typing rules for language boundaries insert lumps when going from to , and remove them when going back from to . In particular, arbitrary linear types cannot occur at the boundary, they must be of the form .
Finally, boundaries have reduction rules: a term or configuration inside a boundary in reduction position is reduced until it becomes a value, and then a lump is added or removed depending on the boundary direction. Note that because the in is at a duplicable type , we know by inversion that the store is empty.
3.2 Interoperability: Static Semantics
If the linear language could not interact with lumped values at all, our multilanguage programs would be rather boring, as the only way for the linear extension to provide a value back to ML would be to have received it from and pass it back unchanged (as in the lump embedding of Matthews and Findler (2009)). To provide a real interaction, we provide a way to extract values out of a lump , use it at some linear type , and put it back in before sending the result to .
The correspondence between intuitionistic types and linear types is specified by a heterogeneous compatibility relation – defined in full in Fig. 7. The specification of this relation is that if holds, then the space of values of and are isomorphic: we can convert back and forth between them. When this relation holds, the termformers and perform the conversion.
The term turns a into a lumped type , and we need to unlump it with some for a compatible to interact with it on the linear side. It is common to combine both operations and we provide syntactic sugar for it: . Similarly first lumps a linear term then sends the result to the ML world.
3.3 Interoperability: Dynamic Semantics
When the relation holds, we can define a relation between the values of and the values of – see the long version of this work. It is functional in both direction: with our definition is uniquely determined from and conversely. We then define the reduction rule for (un)lumping: if , then
3.4 Full Abstraction from into
We can now state the major metatheoretical result of this work, which is the proposed multilanguage design extends the simple language in a way that provably has, in a certain sense, “no abstraction leaks”.
Definition 1
(Contextual equivalence in ). We say that such that are contextually equivalent, written , if, for any expression context such that , the closed terms and are equiterminating.
Definition 2
(Contextual equivalence in ). We say that such that are contextually equivalent, written , if, for any expression context such that , the closed terms and are equiterminating.
Theorem 2
(Full Abstraction). The embedding of into is fullyabstract:
4 Conclusion and Related Work
Having a stack of usable, interoperable languages, extensions or dialects is at the forefront of the Racket approach to programming environments, in particular for teaching (Felleisen et al. 2004).
Our multilanguage semantics builds on the seminal work by Matthews and Findler (2009), who gave a formal semantics of interoperability between a dynamically and a statically typed language. Others have followed the MatthewsFindler approach of designing multilanguage systems with finegrained boundaries—for instance, formalizing interoperability between a simply and dependently typed language (Osera et al. 2012); between a functional and typed assembly language (Patterson et al. 2017); between an MLlike and an affinely typed language, where linearity is enforced at runtime on the ML side using stateful contracts (Tov and Pucella 2010); and between the source and target languages of compilation to specify compiler correctness (Perconti and Ahmed 2014). However, all these papers address only the question of soundness of the multilanguage; we propose a formal treatment of usability and absence of abstraction leaks.
The only work to establish that a language embeds into a multilanguage in a fully abstract way is the work on fully abstract compilation by Ahmed and Blume (2011) and New et al. (2016) who show that their compiler’s source language embeds into their sourcetarget multilanguage in a fully abstract way. But the focus of this work was on fully abstract compilation, not on usability of userfacing languages.
The Eco project (Barrett et al. 2016) is studying multilanguage systems where userexposed languages are combined in a very finegrained way; it is closely related in that it studies the user experience in a multilanguage system. The choice of an existing dynamic language creates delicate interoperability issues (conflicting variable scoping rules, etc.) as well as performance challenges. We propose a different approach, to design new multilanguages from scratch with interoperability in mind to avoid legacy obstacles.
We are not aware of existing systems exploiting the simple idea of using promotion to capture uniquelyowned state and dereliction to copy it—common formulations would rather perform copies on the contraction rule.
The general idea that linear types can permit reuse of unused allocated cells is not new. In Wadler (1990), a system is proposed with both linear and nonlinear types to attack precisely this problem. It is however more distant from standard linear logic and somewhat adhoc; for example, there is no way to permanently turn a uniquelyowned value into a shared value, it provides instead a local borrowing construction that comes with adhoc restrictions necessary for safety. (The inability to give up unique ownership, which is essential in our listprogramming examples, seems to also be missing from Rust, where one would need to perform a costly operation of traversing the graph of the value to turn all pointers into Arc nodes.)
The RAML project (Hoffmann et al. 2012) also combines linear logic and memory reuse: its destructive match operator will implicitly reuse consumed cells in new allocations occurring within the match body. Multilanguages give us the option to explore more explicit, flexible representations of those lowlevel concern, without imposing the complexity to all programmers.
A recent related work is the Cogent language (O’Connor et al. 2016), in which linear state is also viewed as both functional and imperative – the latter view enabling memory reuse. The language design is interestingly reversed: in Cogent, the linear layer is the simple language that everyone uses, and the nonlinear language is a complex but powerful language that is used when one really has to, named C.
Our linear language is sensibly simpler, and in several ways less expressive, than advanced programming languages based on linear logic (Tov and Pucella 2011), separation logic (Balabonski et al. 2016), finegrained permissions (Garcia et al. 2014): it is not designed to stand on its own, but to serve as a useful sidekick to a functional language, allowing safer resource handling.
One major simplification of our design compared to more advanced linear or separationlogicbased languages is that we do not separate physical locations from the logical capability/permission to access them (e.g., as in Ahmed et al. (2007)). This restricts expressiveness in wellunderstood ways (Fahndrich and DeLine 2002): shared values cannot point to linear values.
Alms (Tov and Pucella 2011), Quill (Morris 2016) and Linear Haskell (Bernardy et al. 2018) add linear types to a functional language, trying hard not to lose desirable usability property, such as type inference or the genericity of polymorphic higherorder functions. This is very challenging; for example, Linear Haskell gives up on principality of inference^{Footnote 4}. Our multilanguage design sidesteps this issue as the generalpurpose language remains unchanged. Language boundaries are more rigid than an ideal nocompromise language, as they force users to preserve the distinction between the generalpurpose and the advanced features; it is precisely this compromise that gives a design of reduced complexity.
Finally, on the side of the semantics, our system is related to LNL (Benton 1994), a calculus for linear logic that, in a sense, is itself built as a multilanguage system where (nonduplicable) linear types and (duplicable) intuitionistic types interact through a boundary. It is not surprising that our design contains an instance of this adjunction: for any there is a unique such that , and converting a value to this and back gives a and is provably equivalent, by boundary cancellation, to just using .
Notes
 1.
 2.
 3.
Standard presentations of linear logic force contexts to be completely distinct, but have a separate rule to duplicate linear variables, which is less natural for programming.
 4.
Thanks to Stephen Dolan for pointing out that \(\lambda f. \lambda x.\,f~x\) has several incompatible Linear Haskell types.
References
Abramsky, S., Jagadeesan, R., Malacaria, P.: Full abstraction for PCF. Inf. Comput. 163(2), 409–470 (2000)
Ahmed, A., Blume, M.: Typed closure conversion preserves observational equivalence. In: International Conference on Functional Programming (ICFP), Victoria, British Columbia, Canada, pp. 157–168, September 2008
Ahmed, A., Blume, M.: An equivalencepreserving CPS translation via multilanguage semantics. In: International Conference on Functional Programming (ICFP), Tokyo, Japan, pp. 431–444, September 2011
Ahmed, A., Fluet, M., Morrisett, G.: L3: a linear language with locations. Fundamenta Informaticae 77(4), 397–449 (2007)
Balabonski, T., Pottier, F., Protzenko, J.: The design and formalization of Mezzo, a permissionbased programming language. ACM Trans. Program. Lang. Syst. 38(4), 14:1–14:94 (2016)
Barrett, E., Bolz, C.F., Diekmann, L., Tratt, L.: Finegrained language composition: a case study. In: ECOOP (2016)
Benton, P.N.: A mixed linear and nonlinear logic: proofs, terms and models. In: Pacholski, L., Tiuryn, J. (eds.) CSL 1994. LNCS, vol. 933, pp. 121–135. Springer, Heidelberg (1995). https://doi.org/10.1007/BFb0022251
Bernardy, J.P., Boespflug, M., Newton, R.R., Jones, S.P., Spiwack, A.: Linear haskell: practical linearity in a higherorder polymorphic language. PACMPL 2(POPL), 5:1–5:29 (2018). https://doi.org/10.1145/3158093
Cartwright, R., Felleisen, M.: Observable sequentiality and full abstraction. In: ACM Symposium on Principles of Programming Languages (POPL), Albuquerque, New Mexico, pp. 328–342 (1992)
Devriese, D., Patrignani, M., Piessens, F.: Fullyabstract compilation by approximate backtranslation. In: ACM Symposium on Principles of Programming Languages (POPL), St. Petersburg, Florida (2016)
Fahndrich, M., DeLine, R.: Adoption and focus: practical linear types for imperative programming. In: PLDI 2002 (2002)
Felleisen, M., Findler, R.B., Flatt, M., Krishnamurthi, S.: The teachscheme! project: computing and programming for every student. Comput. Sci. Educ. 14(1), 55–77 (2004)
Garcia, R., Tanter, É., Wolff, R., Aldrich, J.: Foundations of typestateoriented programming. TOPLAS 36, 12 (2014)
Hoffmann, J., Aehlig, K., Hofmann, M.: Resource aware ML. In: Madhusudan, P., Seshia, S.A. (eds.) CAV 2012. LNCS, vol. 7358, pp. 781–786. Springer, Heidelberg (2012). https://doi.org/10.1007/9783642314247_64
Jeffrey, A., Rathke, J.: Java JR: fully abstract trace semantics for a Core Java Language. In: Sagiv, M. (ed.) ESOP 2005. LNCS, vol. 3444, pp. 423–438. Springer, Heidelberg (2005). https://doi.org/10.1007/9783540319870_29
Matthews, J., Findler, R.B.: Operational semantics for multilanguage programs. ACM Trans. Program. Lang. Syst. (TOPLAS) 31(3), 12 (2009)
Meyer, A.R., Sieber, K.: Towards fully abstract semantics for local variables. In: ACM Symposium on Principles of Programming Languages (POPL), San Diego, California, pp. 191–203 (1988)
Milner, R.: Fully abstract models of typed lambda calculi. Theor. Comput. Sci. 4(1), 1–22 (1977)
Morris, J.G.: The best of both worlds: linear functional programming without compromise. In: ICFP (2016)
New, M.S., Bowman, W.J., Ahmed, A.: Fully abstract compilation via universal embedding. In: International Conference on Functional Programming (ICFP), Nara, Japan, September 2016
O’Connor, L., Chen, Z., Rizkallah, C., Amani, S., Lim, J., Murray, T., Nagashima, Y., Sewell, T., Klein, G.: Refinement through restraint: bringing down the cost of verification. In: ICFP (2016)
Osera, P.M., Sjöberg, V., Zdancewic, S.: Dependent interoperability. In: Programming Languages Meets Program Verification (PLPV), January 2012
Patrignani, M., Agten, P., Strackx, R., Jacobs, B., Clarke, D., Piessens, F.: Secure compilation to protected module architectures. ACM Trans. Program. Lang. Syst. 37(2), 6:1–6:50 (2015)
Patterson, D., Perconti, J., Dimoulas, C., Ahmed, A.: FunTAL: reasonably mixing a functional language with assembly. In: ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI), Barcelona, Spain, June 2017. http://www.ccs.neu.edu/home/amal/papers/funtal.pdf
Perconti, J.T., Ahmed, A.: Verifying an open compiler using multilanguage semantics. In: Shao, Z. (ed.) ESOP 2014. LNCS, vol. 8410, pp. 128–148. Springer, Heidelberg (2014). https://doi.org/10.1007/9783642548338_8
Tov, J.A., Pucella, R.: Stateful contracts for affine types. In: Gordon, A.D. (ed.) ESOP 2010. LNCS, vol. 6012, pp. 550–569. Springer, Heidelberg (2010). https://doi.org/10.1007/9783642119576_29
Tov, J.A., Pucella, R.: Practical affine types. In: POPL (2011)
Wadler, P.: Linear types can change the world! In: Programming Concepts and Methods (1990)
Acknowledgments
We thank our anonymous reviewers for their feedback, as well as Neelakantan Krishnaswami, François Pottier, Jennifer Paykin, Sylvie Boldot and Simon PeytonJones for our discussions on this work.
This work was supported in part by the National Science Foundation under grants CCF1422133 and CCF1453796, and the European Research Council under ERC Starting Grant SECOMP (715753). Any opinions, findings, and conclusions expressed in this material are those of the authors and do not necessarily reflect the views of our funding agencies.
Author information
Affiliations
Corresponding author
Rights and permissions
This chapter is published under an open access license. Please check the 'Copyright Information' section either on this page or in the PDF for details of this license and what reuse is permitted. If your intended use exceeds what is permitted by the license or if you are unable to locate the licence and reuse information, please contact the Rights and Permissions team.
Copyright information
© 2018 The Author(s)
About this paper
Cite this paper
Scherer, G., New, M., Rioux, N., Ahmed, A. (2018). Fabous Interoperability for ML and a Linear Language. In: Baier, C., Dal Lago, U. (eds) Foundations of Software Science and Computation Structures. FoSSaCS 2018. Lecture Notes in Computer Science(), vol 10803. Springer, Cham. https://doi.org/10.1007/9783319893662_8
Download citation
DOI: https://doi.org/10.1007/9783319893662_8
Published:
Publisher Name: Springer, Cham
Print ISBN: 9783319893655
Online ISBN: 9783319893662
eBook Packages: Computer ScienceComputer Science (R0)