A fully abstract model of a programming language assigns the same meaning to two terms if and only if they have the same operational behavior. Such models are well-known for functional languages but little is known about extended functional languages with sophisticated control structures. We show that a direct model with error values and the conventional continuation model are adequate for functional languages augmented with first- and higher-order control facilities, respectively. Furthermore, both models become fully abstract on adding a control delimiter and a parallel conditional to the programming languages.
{"title":"Reasoning with continuations II: full abstraction for models of control","authors":"Dorai Sitaram, M. Felleisen","doi":"10.1145/91556.91626","DOIUrl":"https://doi.org/10.1145/91556.91626","url":null,"abstract":"A fully abstract model of a programming language assigns the same meaning to two terms if and only if they have the same operational behavior. Such models are well-known for functional languages but little is known about extended functional languages with sophisticated control structures. We show that a direct model with error values and the conventional continuation model are adequate for functional languages augmented with first- and higher-order control facilities, respectively. Furthermore, both models become fully abstract on adding a control delimiter and a parallel conditional to the programming languages.","PeriodicalId":409945,"journal":{"name":"LISP and Functional Programming","volume":null,"pages":null},"PeriodicalIF":0.0,"publicationDate":"1990-05-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"120830003","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
The Scheme dialect of Lisp [9] is properly tail-recuraiwit relies entirely on procedure calls to express iteration. In Scheme, a tail-recursive procedure call (that is, a call in which the calling procedure does not do any further processing of the returned due) is essentially a goto that passes arguments, sa was first pointed out by Steele [13]. In a prop erly tail-recursive language, there is no need for any explicit iteration constructs such as do or vhile; these can all be defined in terms of ordinary procedure calls. As elegant as tail-recursion may be from the perspective of the programmer or the theoretician, it poses challenges for the compiler designer. One of the crucial decisions in the design of a compiler is the formation of a strategy for memory allocation and deallocation. An important aspect of this strategy is the treatment of memory locations used to hold the bindings of local variables. Because local variables play a significant role in most computer languages, their treatment can have a noticeable impact on a program’s execution speed and run-time space requirements. Compilers for many block-structured languages use a simple strategy when allocating local variables: stack allocation. This strategy is supported by hardware on many computers, and by software mechanisms such as the aceem link and the display. However, the standard methods for implementing stack allocation assume that the language is not tail-recursive, and a straightforward application of these methods to a tailrecursive language can result in non-tail-recursive compiled code.’ This paper describes stack-allocation techniques for compiling tail-recursive languages. We do not claim that these are the only techniquea that can be used to solve the prob lem, nor do we compare them to other techniques. Instead, we use our techniques as a concrete example to demonstrate that it is possible to implement stack allocation of local variables without sacrificing tail recursion, which to our knowledge has not previously been shown. We have implemented these techniques in the MIT
{"title":"Efficient stack allocation for tail-recursive languages","authors":"C. Hanson","doi":"10.1145/91556.91603","DOIUrl":"https://doi.org/10.1145/91556.91603","url":null,"abstract":"The Scheme dialect of Lisp [9] is properly tail-recuraiwit relies entirely on procedure calls to express iteration. In Scheme, a tail-recursive procedure call (that is, a call in which the calling procedure does not do any further processing of the returned due) is essentially a goto that passes arguments, sa was first pointed out by Steele [13]. In a prop erly tail-recursive language, there is no need for any explicit iteration constructs such as do or vhile; these can all be defined in terms of ordinary procedure calls. As elegant as tail-recursion may be from the perspective of the programmer or the theoretician, it poses challenges for the compiler designer. One of the crucial decisions in the design of a compiler is the formation of a strategy for memory allocation and deallocation. An important aspect of this strategy is the treatment of memory locations used to hold the bindings of local variables. Because local variables play a significant role in most computer languages, their treatment can have a noticeable impact on a program’s execution speed and run-time space requirements. Compilers for many block-structured languages use a simple strategy when allocating local variables: stack allocation. This strategy is supported by hardware on many computers, and by software mechanisms such as the aceem link and the display. However, the standard methods for implementing stack allocation assume that the language is not tail-recursive, and a straightforward application of these methods to a tailrecursive language can result in non-tail-recursive compiled code.’ This paper describes stack-allocation techniques for compiling tail-recursive languages. We do not claim that these are the only techniquea that can be used to solve the prob lem, nor do we compare them to other techniques. Instead, we use our techniques as a concrete example to demonstrate that it is possible to implement stack allocation of local variables without sacrificing tail recursion, which to our knowledge has not previously been shown. We have implemented these techniques in the MIT","PeriodicalId":409945,"journal":{"name":"LISP and Functional Programming","volume":null,"pages":null},"PeriodicalIF":0.0,"publicationDate":"1990-05-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"125965240","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Projection analysis is a technique for finding out information about lazy functional programs. We show how the information obtained from this analysis can be used to speed up sequential implementations, and introduce parallelism into parallel implementations. The underlying evaluation model is evaluation transformers, where the amount of evaluation that is allowed of an argument in a function application depends on the amount of evaluation allowed of the application. We prove that the transformed programs preserve the semantics of the original programs. Compilation rules, which encode the information from the analysis, are given for sequential and parallel machines.
{"title":"Using projection analysis of evaluation-order and its application","authors":"G. Burn","doi":"10.1145/91556.91655","DOIUrl":"https://doi.org/10.1145/91556.91655","url":null,"abstract":"Projection analysis is a technique for finding out information about lazy functional programs. We show how the information obtained from this analysis can be used to speed up sequential implementations, and introduce parallelism into parallel implementations. The underlying evaluation model is evaluation transformers, where the amount of evaluation that is allowed of an argument in a function application depends on the amount of evaluation allowed of the application. We prove that the transformed programs preserve the semantics of the original programs.\u0000Compilation rules, which encode the information from the analysis, are given for sequential and parallel machines.","PeriodicalId":409945,"journal":{"name":"LISP and Functional Programming","volume":null,"pages":null},"PeriodicalIF":0.0,"publicationDate":"1990-05-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"133990397","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
A representation for lambda terms is described based on the scheme of de Bruijn for eliminating variable names. The new notation provides for a class of terms that can encode other terms together with substitutions to be performed on them. The notion of an environment is used to realize this “delaying” of substitutions. The precise mechanism that is used is, however, more complex than the usual so as to support the ability to examine subterms embedded under abstractions. A virtue of our representation is that it permits substitution to be realized as an atomic operation and thereby provides for efficient implementations of β-reduction. Operations on lgr;-terms are described based on our representation and the relationship of these to the conventional definitions are exhibited.
{"title":"A representation of Lambda terms suitable for operations on their intensions","authors":"G. Nadathur, D. S. Wilson","doi":"10.1145/91556.91682","DOIUrl":"https://doi.org/10.1145/91556.91682","url":null,"abstract":"A representation for lambda terms is described based on the scheme of de Bruijn for eliminating variable names. The new notation provides for a class of terms that can encode other terms together with substitutions to be performed on them. The notion of an environment is used to realize this “delaying” of substitutions. The precise mechanism that is used is, however, more complex than the usual so as to support the ability to examine subterms embedded under abstractions. A virtue of our representation is that it permits substitution to be realized as an atomic operation and thereby provides for efficient implementations of β-reduction. Operations on lgr;-terms are described based on our representation and the relationship of these to the conventional definitions are exhibited.","PeriodicalId":409945,"journal":{"name":"LISP and Functional Programming","volume":null,"pages":null},"PeriodicalIF":0.0,"publicationDate":"1990-05-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"121498812","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
It has been claimed for a long time that functional languages are attractive candidates for execution on parallel architectures. This belief is based on the fact that functional programs are free of side effects and often contain a great deal of implicit parallelism. However the first parallel implementations of functional languages [Vegdahl 841 didn’t really support this claim because they were based on a somewhat dogmatic view of parallelism : the normal execution mode was supposed to be the parallel mode, the extreme consequence being that each expression might be considered as a process. The uniformity of this approach makes it attractive in theory but it is not really effective (at least in the present state of the art in hardware technology) because it entails significant overhead costs that may outweigh any benefit gained from exploiting parallelism. It is now recognized that a parallel implementation of a functional language must satisfy two criteria in order to be competitive :
{"title":"Continuation-based parallel implementation of functional programming languages","authors":"J. Giorgi, D. Métayer","doi":"10.1145/91556.91648","DOIUrl":"https://doi.org/10.1145/91556.91648","url":null,"abstract":"It has been claimed for a long time that functional languages are attractive candidates for execution on parallel architectures. This belief is based on the fact that functional programs are free of side effects and often contain a great deal of implicit parallelism. However the first parallel implementations of functional languages [Vegdahl 841 didn’t really support this claim because they were based on a somewhat dogmatic view of parallelism : the normal execution mode was supposed to be the parallel mode, the extreme consequence being that each expression might be considered as a process. The uniformity of this approach makes it attractive in theory but it is not really effective (at least in the present state of the art in hardware technology) because it entails significant overhead costs that may outweigh any benefit gained from exploiting parallelism. It is now recognized that a parallel implementation of a functional language must satisfy two criteria in order to be competitive :","PeriodicalId":409945,"journal":{"name":"LISP and Functional Programming","volume":null,"pages":null},"PeriodicalIF":0.0,"publicationDate":"1990-05-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"127621059","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
This paper relates two views of the operational semantics of a language with multiple inheritance. It is shown that the introduction of explicit coercions as an interpretation for the implicit coercion of inheritance does not affect the evaluation of a program in an essential way. The result is proved by semantic means using a denotational model and a computational adequacy result to relate the operational and denotational semantics.
{"title":"Computing with coercions","authors":"V. Tannen, Carl A. Gunter, A. Scedrov","doi":"10.1145/91556.91590","DOIUrl":"https://doi.org/10.1145/91556.91590","url":null,"abstract":"This paper relates two views of the operational semantics of a language with multiple inheritance. It is shown that the introduction of explicit coercions as an interpretation for the implicit coercion of inheritance does not affect the evaluation of a program in an essential way. The result is proved by semantic means using a denotational model and a computational adequacy result to relate the operational and denotational semantics.","PeriodicalId":409945,"journal":{"name":"LISP and Functional Programming","volume":null,"pages":null},"PeriodicalIF":0.0,"publicationDate":"1990-05-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"116703093","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
There have been many demonstrations that the expressive power of Lisp can greatly simplify the process of writing numerical programs, but at the cost of reduced performance.[10][16] I show that by coupling Lisp's abstract, expressive style of programming with a compiler that uses partial evaluation, data abstractions can be eliminated at compile time, producing extremely high-performance code. For an important class of numerical programs, partial evaluation achieves order-of-magnitude speed-ups over conventional Lisp compilation technology. This approach has proven to be especially effective when used in conjunction with schedulers for VLIW and highly pipelined architectures, because the elimination of data structures and procedural abstractions exposes the low-level parallelism inherent in a computation.
{"title":"Partial evaluation applied to numerical computation","authors":"A. Berlin","doi":"10.1145/91556.91612","DOIUrl":"https://doi.org/10.1145/91556.91612","url":null,"abstract":"There have been many demonstrations that the expressive power of Lisp can greatly simplify the process of writing numerical programs, but at the cost of reduced performance.[10][16] I show that by coupling Lisp's abstract, expressive style of programming with a compiler that uses partial evaluation, data abstractions can be eliminated at compile time, producing extremely high-performance code. For an important class of numerical programs, partial evaluation achieves order-of-magnitude speed-ups over conventional Lisp compilation technology. This approach has proven to be especially effective when used in conjunction with schedulers for VLIW and highly pipelined architectures, because the elimination of data structures and procedural abstractions exposes the low-level parallelism inherent in a computation.","PeriodicalId":409945,"journal":{"name":"LISP and Functional Programming","volume":null,"pages":null},"PeriodicalIF":0.0,"publicationDate":"1990-05-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"115626350","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Polymorphic typing comes in two flavors: parametric as in ML and in Girard-Reynolds’s second order X-calculus 2X, and discrete as in Forsyth [Rey88] and Coppo-Dezani’s X-calculus with intersection types, JX. At first blush, intersection types might look as the ultimate form of discrete polymorphism, since all normalizable X-expressions are (suitably) typable. However, the typings obtained in JX for normalizable X-expressions may be highly non-uniform. For instance, if P is a X-expression representing a unary numeric [unction f, then Pii will be typable for every Church numeral ii, but there may be no type T common to all numerals and such that P has a type of the form r + . . . (see Theorem 14 below). Thus, while intersection-types serve well a.s guarantor of functional well-behavior, for each individual input, they are not all-powerful as compile-time checks for the functional well-behavior of procedures as a whole. We consider here a discipline JmX with infinite type int,ersection, for which we outline a mathematical theory. This has several advantages:
多态分两种类型:参数型如ML和Girard-Reynolds二阶X-calculus 2X，离散型如Forsyth [Rey88]和Coppo-Dezani的X-calculus with intersection types, JX。乍一看，交叉类型可能看起来像是离散多态性的最终形式，因为所有可规范化的x表达式都是(适当地)可类型的。但是，在JX中为可规范化的x表达式获得的类型可能高度不一致。例如，如果P是表示一元数值函数f的x表达式，则Pii将可用于所有教会数字ii，但可能没有所有数字共有的类型T，因此P具有形式为r +…(见定理14)。因此，虽然交叉类型作为功能良好行为的保证人很好地服务，但对于每个单独的输入，它们并不是作为整个过程的功能良好行为的编译时检查的全能。我们在这里考虑一个具有无限类型int的学科JmX，我们为它概述了一个数学理论。这有几个好处:
{"title":"Discrete polymorphism","authors":"D. Leivant","doi":"10.1145/91556.91675","DOIUrl":"https://doi.org/10.1145/91556.91675","url":null,"abstract":"Polymorphic typing comes in two flavors: parametric as in ML and in Girard-Reynolds’s second order X-calculus 2X, and discrete as in Forsyth [Rey88] and Coppo-Dezani’s X-calculus with intersection types, JX. At first blush, intersection types might look as the ultimate form of discrete polymorphism, since all normalizable X-expressions are (suitably) typable. However, the typings obtained in JX for normalizable X-expressions may be highly non-uniform. For instance, if P is a X-expression representing a unary numeric [unction f, then Pii will be typable for every Church numeral ii, but there may be no type T common to all numerals and such that P has a type of the form r + . . . (see Theorem 14 below). Thus, while intersection-types serve well a.s guarantor of functional well-behavior, for each individual input, they are not all-powerful as compile-time checks for the functional well-behavior of procedures as a whole. We consider here a discipline JmX with infinite type int,ersection, for which we outline a mathematical theory. This has several advantages:","PeriodicalId":409945,"journal":{"name":"LISP and Functional Programming","volume":null,"pages":null},"PeriodicalIF":0.0,"publicationDate":"1990-05-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"130345288","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Functional programming languages remove programmers from low-level machine details, an important achievement when programming massively parallel systems. We present an overview of an FP compiler that generates programs capable of exploiting data-parallelism, a view of parallelism where distinct data elements reside on distinct processors and all processors execute a single instruction stream. To achieve this form of parallelism, FP's sequences are represented as arrays. This representation makes possible optimization techniques developed for APL compilers that compose routing functions at compile-time. These techniques are described succinctly by a set of axioms and inference rules. We demonstrate the optimizations by compiling several FP functions, obtaining optimal performance.
{"title":"A functional programming language compiler for massively parallel computers","authors":"Clifford Walinsky, Deb Banerjee","doi":"10.1145/91556.91610","DOIUrl":"https://doi.org/10.1145/91556.91610","url":null,"abstract":"Functional programming languages remove programmers from low-level machine details, an important achievement when programming massively parallel systems. We present an overview of an FP compiler that generates programs capable of exploiting data-parallelism, a view of parallelism where distinct data elements reside on distinct processors and all processors execute a single instruction stream. To achieve this form of parallelism, FP's sequences are represented as arrays. This representation makes possible optimization techniques developed for APL compilers that compose routing functions at compile-time. These techniques are described succinctly by a set of axioms and inference rules. We demonstrate the optimizations by compiling several FP functions, obtaining optimal performance.","PeriodicalId":409945,"journal":{"name":"LISP and Functional Programming","volume":null,"pages":null},"PeriodicalIF":0.0,"publicationDate":"1990-05-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"121992635","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
We have built a novel and efficient replay debugger for our Standard ML compiler. Debugging facilities are provided by instrumenting the user's source code; this approach, made feasible by ML's safety property, is machine-independent and back-end independent. Replay is practical because ML is normally used functionally, and our compiler uses continuation-passing style; thus most of the program's state can be checkpointed quickly and compactly using call-with-current-continuation. Together, instrumentation and replay support a simple and elegant debugger featuring full variable display, polymorphic type resolution, stack trace-back, breakpointing, and reverse execution, even though our compiler is very highly optimizing and has no run-time stack.
{"title":"Debugging standard ML without reverse engineering","authors":"A. Tolmach, A. Appel","doi":"10.1145/91556.91564","DOIUrl":"https://doi.org/10.1145/91556.91564","url":null,"abstract":"We have built a novel and efficient replay debugger for our Standard ML compiler. Debugging facilities are provided by instrumenting the user's source code; this approach, made feasible by ML's safety property, is machine-independent and back-end independent. Replay is practical because ML is normally used functionally, and our compiler uses continuation-passing style; thus most of the program's state can be checkpointed quickly and compactly using call-with-current-continuation. Together, instrumentation and replay support a simple and elegant debugger featuring full variable display, polymorphic type resolution, stack trace-back, breakpointing, and reverse execution, even though our compiler is very highly optimizing and has no run-time stack.","PeriodicalId":409945,"journal":{"name":"LISP and Functional Programming","volume":null,"pages":null},"PeriodicalIF":0.0,"publicationDate":"1990-05-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"130345372","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
京公网安备 11010802042870号
京ICP备2023020795号-1
扫码关注我们
求助内容：
应助结果提醒方式：