Results 11  20
of
418
Type classes in Haskell
 ACM Transactions on Programming Languages and Systems
, 1996
"... This paper de nes a set of type inference rules for resolving overloading introduced by type classes. Programs including type classes are transformed into ones which may be typed by the HindleyMilner inference rules. In contrast to other work on type classes, the rules presented here relate directl ..."
Abstract

Cited by 121 (5 self)
 Add to MetaCart
This paper de nes a set of type inference rules for resolving overloading introduced by type classes. Programs including type classes are transformed into ones which may be typed by the HindleyMilner inference rules. In contrast to other work on type classes, the rules presented here relate directly to user programs. An innovative aspect of this work is the use of secondorder lambda calculus to record type information in the program. 1.
Confluence properties of Weak and Strong Calculi of Explicit Substitutions
 JOURNAL OF THE ACM
, 1996
"... Categorical combinators [12, 21, 43] and more recently oecalculus [1, 23], have been introduced to provide an explicit treatment of substitutions in the calculus. We reintroduce here the ingredients of these calculi in a selfcontained and stepwise way, with a special emphasis on confluence prope ..."
Abstract

Cited by 120 (7 self)
 Add to MetaCart
Categorical combinators [12, 21, 43] and more recently oecalculus [1, 23], have been introduced to provide an explicit treatment of substitutions in the calculus. We reintroduce here the ingredients of these calculi in a selfcontained and stepwise way, with a special emphasis on confluence properties. The main new results of the paper w.r.t. [12, 21, 1, 23] are the following: 1. We present a confluent weak calculus of substitutions, where no variable clashes can be feared. 2. We solve a conjecture raised in [1]: oecalculus is not confluent (it is confluent on ground terms only). This unfortunate result is "repaired" by presenting a confluent version of oecalculus, named the Envcalculus in [23], called here the confluent oecalculus.
Unboxed values as first class citizens in a nonstrict functional language
 Proceedings of the 5th ACM conference on Functional programming languages and computer architecture
, 1991
"... The code compiled from a nonstrict functional program usually manipulates heapallocated boxed numbers. Compilers for such languages often go to considerable trouble to optimise operations on boxed numbers into simpler operations on their unboxed forms. These optimisations are usually handled in an ..."
Abstract

Cited by 107 (15 self)
 Add to MetaCart
The code compiled from a nonstrict functional program usually manipulates heapallocated boxed numbers. Compilers for such languages often go to considerable trouble to optimise operations on boxed numbers into simpler operations on their unboxed forms. These optimisations are usually handled in an ad hoc manner in the code generator, because earlier phases of the compiler have no way to talk about unboxed values.
We present a new approach, which makes unboxed values into (nearly) firstclass citizens. The language, including its type system, is extended to handle unboxed values. The optimisation of boxing and unboxing operations can now be reinterpreted as a set of correctnesspreserving program transformations. Indeed the particular transformations required are ones which a compiler would want to implement anyway. The compiler becomes both simpler and more modular.
Two other benefits accrue. Firstly, the results of strictness analysis can be exploited within the same uniform transformational framework. Secondly, new algebraic data types with unboxed components can be declared. Values of these types can be manipulated much more efficiently than the corresponding boxed versions.
Both a static and a dynamic semantics are given for the augmented language. The denotational dynamic semantics is notable for its use of unpointed domains.
A transformationbased optimiser for Haskell
, 1998
"... Many compilers do some of their work by means of correctnesspreserving, and hopefully performanceimproving, program transformations. The Glasgow Haskell Compiler (GHC) takes this idea of "compilation by transformation" as its warcry, trying to express as much as possible of the compilation proces ..."
Abstract

Cited by 84 (11 self)
 Add to MetaCart
Many compilers do some of their work by means of correctnesspreserving, and hopefully performanceimproving, program transformations. The Glasgow Haskell Compiler (GHC) takes this idea of "compilation by transformation" as its warcry, trying to express as much as possible of the compilation process in the form of program transformations. This paper reports on our practical experience of the transformational approach to compilation, in the context of a substantial compiler.
Higherorder narrowing with definitional trees
 Neural Computation
, 1996
"... Functional logic languages with a sound and complete operational semantics are mainly based on narrowing. Due to the huge search space of simple narrowing, steadily improved narrowing strategies have been developed in the past. Needed narrowing is currently the best narrowing strategy for firstord ..."
Abstract

Cited by 78 (23 self)
 Add to MetaCart
Functional logic languages with a sound and complete operational semantics are mainly based on narrowing. Due to the huge search space of simple narrowing, steadily improved narrowing strategies have been developed in the past. Needed narrowing is currently the best narrowing strategy for firstorder functional logic programs due to its optimality properties w.r.t. the length of derivations and the number of computed solutions. In this paper, we extend the needed narrowing strategy to higherorder functions and λterms as data structures. By the use of definitional trees, our strategy computes only incomparable solutions. Thus, it is the first calculus for higherorder functional logic programming which provides for such an optimality result. Since we allow higherorder logical variables denoting λterms, applications go beyond current functional and logic programming languages.
Typed Concurrent Objects
 In Proceedings of the Eighth European Conference on Object Oriented Programming (ECOOP
"... Based on a namepassing calculus and on its typing system the paper shows how to build several language constructors towards a stronglytyped objectoriented concurrent programming language. The basic calculus incorporates the notions of asynchronous labelled messages, concurrent objects composed of ..."
Abstract

Cited by 71 (10 self)
 Add to MetaCart
Based on a namepassing calculus and on its typing system the paper shows how to build several language constructors towards a stronglytyped objectoriented concurrent programming language. The basic calculus incorporates the notions of asynchronous labelled messages, concurrent objects composed of labelled methods, and a form of abstraction on processes allowing in particular to declare polymorphic classes. We introduce a notion of values as nameexpressions, and show how to create subclasses of existing classes. A systematic translation of the derived constructors into the basic calculus provides for semantics and for typing rules for the new constructors.
Using Parameterized Signatures to Express Modular Structure
 POPL'96
, 1996
"... Module systems are a powerful, practical tool for managing the complexity of large software systems. Previous attempts to formulate a typetheoretic foundation for modular programming have been based on existential, dependent, or manifest types. These approaches can be distinguished by their use of ..."
Abstract

Cited by 67 (1 self)
 Add to MetaCart
Module systems are a powerful, practical tool for managing the complexity of large software systems. Previous attempts to formulate a typetheoretic foundation for modular programming have been based on existential, dependent, or manifest types. These approaches can be distinguished by their use of different quantifiers to package the operations that a module exports together with appropriate implementation types. In each case, the underlying type theory is simple and elegant, but significant and sometimes complex extensions are needed to account for features that are im portant in practical systems, such as separate compilation and propagation of type information between modules. This paper presents a simple typetheoretic fi'amework for modular programming using parameterized signatmes. The use of quantifiers is treated as a necessary, but independent concern. Using familiar concepts of polymorphism, the resulting module system is easy to understaud and admits true separate compilation. It is also very powerful, supporting highorder, polymorphic, and firstclass modules without further extension.
Deriving a Lazy Abstract Machine
 Journal of Functional Programming
, 1997
"... Machine Peter Sestoft Department of Mathematics and Physics Royal Veterinary and Agricultural University Thorvaldsensvej 40, DK1871 Frederiksberg C, Denmark Email: sestoft@dina.kvl.dk Version 6 of March 13, 1996 Abstract We derive a simple abstract machine for lazy evaluation of the lambda cal ..."
Abstract

Cited by 67 (2 self)
 Add to MetaCart
Machine Peter Sestoft Department of Mathematics and Physics Royal Veterinary and Agricultural University Thorvaldsensvej 40, DK1871 Frederiksberg C, Denmark Email: sestoft@dina.kvl.dk Version 6 of March 13, 1996 Abstract We derive a simple abstract machine for lazy evaluation of the lambda calculus, starting from Launchbury's natural semantics. Lazy evaluation here means nonstrict evaluation with sharing of argument evaluation, that is, callbyneed. The machine we derive is a lazy version of Krivine's abstract machine, which was originally designed for callbyname evaluation. We extend it with datatype constructors and base values, so the final machine implements all dynamic aspects of a lazy functional language. 1 Introduction The development of an efficient abstract machine for lazy evaluation usually starts from either a graph reduction machine or an environment machine. Graph reduction machines perform substitution by rewriting the term graph, that is, the program itself...
Compiling MultiParadigm Declarative Programs into Prolog
 In Proc. International Workshop on Frontiers of Combining Systems (FroCoS’2000
, 2000
"... This paper describes a highlevel implementation of the concurrent constraint functional logic language Curry. The implementation, directed by the lazy pattern matching strategy of Curry, is obtained by transforming Curry programs into Prolog programs. Contrary to previous transformations of functio ..."
Abstract

Cited by 56 (39 self)
 Add to MetaCart
This paper describes a highlevel implementation of the concurrent constraint functional logic language Curry. The implementation, directed by the lazy pattern matching strategy of Curry, is obtained by transforming Curry programs into Prolog programs. Contrary to previous transformations of functional logic programs into Prolog, our implementation includes new mechanisms for both efficiently performing concurrent evaluation steps and sharing common subterms. The practical results show that our implementation is superior to previously proposed similar implementations of functional logic languages in Prolog and is competitive w.r.t. lowerlevel implementations of Curry in other target languages. An noteworthy advantage of our implementation is the ability to immediately employ in Curry existing constraint solvers for logic programming. In this way, we obtain with a relatively modest effort the implementation of a declarative language combining lazy evaluation, concurrency a...