Results 1 -
5 of
5
The Marriage of Effects and Monads
, 1998
"... this paper is to marry effects to monads, writing T for a computation that yields a value in and may have effects delimited by oe. Now we have that ( is ..."
Abstract
-
Cited by 75 (3 self)
- Add to MetaCart
this paper is to marry effects to monads, writing T for a computation that yields a value in and may have effects delimited by oe. Now we have that ( is
Safe and Principled Language Interoperation
- In European Symposium on Programming (ESOP
, 1999
"... . Safety of interoperation of program fragments written in different safe languages may fail when the languages have different systems of computational effects: an exception raised by an ML function may have no valid semantic interpretation in the context of a Safe-C caller. Sandboxing costs perform ..."
Abstract
-
Cited by 11 (1 self)
- Add to MetaCart
. Safety of interoperation of program fragments written in different safe languages may fail when the languages have different systems of computational effects: an exception raised by an ML function may have no valid semantic interpretation in the context of a Safe-C caller. Sandboxing costs performance and still may violate the semantics if effects are not taken into account. We show that effect annotations alone are insufficient to guarantee safety, and we present a type system with bounded effect polymorphism designed to verify the compatibility of abstract resources required by the computational models of the interoperating languages. The type system ensures single address space interoperability of statically typed languages with effect mechanisms built of modules for control and state. It is shown sound for safety with respect to the semantics of a language with constructs for selection, simulation, and blocking of resources, targeted as an intermediate language for optimization o...
Ordinals and Interactive Programs
, 2000
"... The work reported in this thesis arises from the old idea, going back to the origins of constructive logic, that a proof is fundamentally a kind of program. If proofs can be ..."
Abstract
-
Cited by 5 (2 self)
- Add to MetaCart
The work reported in this thesis arises from the old idea, going back to the origins of constructive logic, that a proof is fundamentally a kind of program. If proofs can be
Type-directed continuation allocation
- In 2nd International Workshop on Types in Compilation, volume 1473 of LNCS
, 1998
"... Abstract. Suppose we translate two different source languages, £¥ ¤ and £§ ¦ , into the same intermediate language; can they safely interoperate in the same address space and under the same runtime system? If £ ¤ supports first-class continuations (call/cc) and £ ¦ does not, can £ ¦ programs call ..."
Abstract
-
Cited by 3 (1 self)
- Add to MetaCart
Abstract. Suppose we translate two different source languages, £¥ ¤ and £§ ¦ , into the same intermediate language; can they safely interoperate in the same address space and under the same runtime system? If £ ¤ supports first-class continuations (call/cc) and £ ¦ does not, can £ ¦ programs call arbitrary £ ¤ functions? Would the fact of possibly calling £¨ ¤ impose restrictions on the implementation strategy of £ ¦ ? Can we compile £ ¤ functions that do not invoke call/cc using more efficient techniques borrowed from the £ ¦ implementation? Our view is that the implementation of a common intermediate language ought to support the so-called pay-as-you-go efficiency: first-order monomorphic functions should be compiled as efficiently as in C and assembly languages, even though they may be passed to arbitrary polymorphic functions that support advanced control primitives (e.g. call/cc). In this paper, we present a typed intermediate language with effect and resource annotations, ensuring the safety of inter-language calls while allowing the compiler to choose continuation allocation strategies. 1
Towards memory reuse in Mercury
- Proceedings of the International Workshop on Implementation of Declarative Languages
, 1999
"... While Mercury allows destructive input/unique output modes which direct the compiler to reuse memory, use of these modes is very cumbersome for the programmer. Moreover it does not fit the declarative programming paradigm where the programmer doesn't have to worry about the details of memory managem ..."
Abstract
-
Cited by 2 (2 self)
- Add to MetaCart
While Mercury allows destructive input/unique output modes which direct the compiler to reuse memory, use of these modes is very cumbersome for the programmer. Moreover it does not fit the declarative programming paradigm where the programmer doesn't have to worry about the details of memory management. The paper briefly reports on some experiments with a prototype analyser which aims at detecting memory available for reuse. The prototype is based on the livestructure analysis developed by us for logic programs extended with declarations. Yet the major contribution of this paper consists of the development of the principles of a module based analysis which are essential for the analysis of large Mercury programs with code distributed over many modules.

