The use of typed intermediate languages can significantly increase the reliability of a compiler. By type-checking the code produced at each transformation stage, one can identify bugs in the compiler that would otherwise be much harder to find. Also it guarantees that any property that was enforced by the source-level type-system is holds also or the generated code. Recently, several people have tried to push this effort a bit further by verifying formally that the compiler indeed preserves typing. This is usually done with proof assistants or experimental languages. Instead, we decided to use Haskell (with GHC's extensions), to see how far we can go with a more mainstream system, supported by robust compilers and plentiful libraries. This article presents one part of our type preserving compiler, namely the closure conversion and its associated hoisting phase, where we use GADTs to let Haskell's type checker verify the we obey the object language's typing rules and that we correctly preserve types from one phase to the other. This should be both a good showcase as well as a good stress test for GADTs, so we also discuss our experience, as well as some trade-offs in the choice of representation, namely between higher-order abstract syntax (HOAS) and a first order representation (i.e. de Bruijn indices) and justify our choice of a de Bruijn representation. We incidentally present a type preserving conversion from HOAS (used in earlier phases of the compiler[6]) to a de Bruijn representation.
{"title":"A type-preserving closure conversion in haskell","authors":"Louis-Julien Guillemette, Stefan Monnier","doi":"10.1145/1291201.1291212","DOIUrl":"https://doi.org/10.1145/1291201.1291212","url":null,"abstract":"The use of typed intermediate languages can significantly increase the reliability of a compiler. By type-checking the code produced at each transformation stage, one can identify bugs in the compiler that would otherwise be much harder to find. Also it guarantees that any property that was enforced by the source-level type-system is holds also or the generated code. Recently, several people have tried to push this effort a bit further by verifying formally that the compiler indeed preserves typing. This is usually done with proof assistants or experimental languages.\u0000 Instead, we decided to use Haskell (with GHC's extensions), to see how far we can go with a more mainstream system, supported by robust compilers and plentiful libraries. This article presents one part of our type preserving compiler, namely the closure conversion and its associated hoisting phase, where we use GADTs to let Haskell's type checker verify the we obey the object language's typing rules and that we correctly preserve types from one phase to the other.\u0000 This should be both a good showcase as well as a good stress test for GADTs, so we also discuss our experience, as well as some trade-offs in the choice of representation, namely between higher-order abstract syntax (HOAS) and a first order representation (i.e. de Bruijn indices) and justify our choice of a de Bruijn representation. We incidentally present a type preserving conversion from HOAS (used in earlier phases of the compiler[6]) to a de Bruijn representation.","PeriodicalId":188691,"journal":{"name":"ACM SIGPLAN Symposium/Workshop on Haskell","volume":"2002 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2007-09-30","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"125763374","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 Glasgow Haskell Compiler (GHC) has quite sophisticated support for concurrency in its runtime system, which is written in low-level C code. As GHC evolves, the runtime system becomes increasingly complex, error-prone, difficult to maintain and difficult to add new concurrency features. This paper presents an alternative approach to implement concurrency in GHC. Rather than hard-wiring all kinds of concurrency features, the runtime system is a thin substrate providing only a small set of concurrency primitives, and the remaining concurrency features are implemented in software libraries written in Haskell. This design improves the safety of concurrency support; it also provides more customizability of concurrency features, which can be developed as Haskell library packages and deployed modularly.
{"title":"Lightweight concurrency primitives for GHC","authors":"Peng Li, S. Marlow, S. Jones, A. Tolmach","doi":"10.1145/1291201.1291217","DOIUrl":"https://doi.org/10.1145/1291201.1291217","url":null,"abstract":"The Glasgow Haskell Compiler (GHC) has quite sophisticated support for concurrency in its runtime system, which is written in low-level C code. As GHC evolves, the runtime system becomes increasingly complex, error-prone, difficult to maintain and difficult to add new concurrency features.\u0000 This paper presents an alternative approach to implement concurrency in GHC. Rather than hard-wiring all kinds of concurrency features, the runtime system is a thin substrate providing only a small set of concurrency primitives, and the remaining concurrency features are implemented in software libraries written in Haskell. This design improves the safety of concurrency support; it also provides more customizability of concurrency features, which can be developed as Haskell library packages and deployed modularly.","PeriodicalId":188691,"journal":{"name":"ACM SIGPLAN Symposium/Workshop on Haskell","volume":"02 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2007-09-30","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"129895192","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 describes the design and construction of a Haskell source-level debugger built into the GHCi interactive environment. We have taken a pragmatic approach: the debugger is based on the traditional stop-examine-continue model of online debugging, which is simple and intuitive, but has traditionally been shunned in the context of Haskell because it exposes the lazy evaluation order. We argue that this drawback is not as severe as it may seem, and in some cases is an advantage. The design focuses on availability: our debugger is intended to work on all programs that can be compiled with GHC, and without requiring the programmer to jump through additional hoops to debug their program. The debugger has a novel approach for reconstructing the type of runtime values in a polymorphic context. Our implementation is light on complexity, and was integrated into GHC without significant upheaval.
{"title":"A lightweight interactive debugger for haskell","authors":"S. Marlow, José Iborra, B. Pope, Andy Gill","doi":"10.1145/1291201.1291204","DOIUrl":"https://doi.org/10.1145/1291201.1291204","url":null,"abstract":"This paper describes the design and construction of a Haskell source-level debugger built into the GHCi interactive environment. We have taken a pragmatic approach: the debugger is based on the traditional stop-examine-continue model of online debugging, which is simple and intuitive, but has traditionally been shunned in the context of Haskell because it exposes the lazy evaluation order. We argue that this drawback is not as severe as it may seem, and in some cases is an advantage.\u0000 The design focuses on availability: our debugger is intended to work on all programs that can be compiled with GHC, and without requiring the programmer to jump through additional hoops to debug their program. The debugger has a novel approach for reconstructing the type of runtime values in a polymorphic context. Our implementation is light on complexity, and was integrated into GHC without significant upheaval.","PeriodicalId":188691,"journal":{"name":"ACM SIGPLAN Symposium/Workshop on Haskell","volume":"43 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2007-09-30","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"125113372","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}
Generic traversals over recursive data structures are often referred to as boilerplate code. The definitions of functions involving such traversals may repeat very similar patterns, but with variations for different data types and different functionality. Libraries of operations abstracting away boilerplate code typically rely on elaborate types to make operations generic. The motivating observation for this paper is that most traversals have value-specific behaviour for just one type. We present the design of a new library exploiting this assumption. Our library allows concise expression of traversals with competitive performance.
{"title":"Uniform boilerplate and list processing","authors":"Neil Mitchell, C. Runciman","doi":"10.1145/1291201.1291208","DOIUrl":"https://doi.org/10.1145/1291201.1291208","url":null,"abstract":"Generic traversals over recursive data structures are often referred to as boilerplate code. The definitions of functions involving such traversals may repeat very similar patterns, but with variations for different data types and different functionality. Libraries of operations abstracting away boilerplate code typically rely on elaborate types to make operations generic. The motivating observation for this paper is that most traversals have value-specific behaviour for just one type. We present the design of a new library exploiting this assumption. Our library allows concise expression of traversals with competitive performance.","PeriodicalId":188691,"journal":{"name":"ACM SIGPLAN Symposium/Workshop on Haskell","volume":" 26","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2007-09-30","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"113952116","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 develop a Haskell library for functional-logic programming, motivated by the implementation of Wired, a relational embedded domain-specific language for describing and analysing digital circuits at the VLSI-layout level. Compared to a previous library for logic programming by Claessen and Ljunglöf, we support residuation, easier creation of logical data types, and pattern matching. We discuss other applications of our library, including test-data generation, and various extensions, including lazy narrowing.
{"title":"A functional-logic library for wired","authors":"Matthew Naylor, E. Axelsson, C. Runciman","doi":"10.1145/1291201.1291207","DOIUrl":"https://doi.org/10.1145/1291201.1291207","url":null,"abstract":"We develop a Haskell library for functional-logic programming, motivated by the implementation of Wired, a relational embedded domain-specific language for describing and analysing digital circuits at the VLSI-layout level. Compared to a previous library for logic programming by Claessen and Ljunglöf, we support residuation, easier creation of logical data types, and pattern matching. We discuss other applications of our library, including test-data generation, and various extensions, including lazy narrowing.","PeriodicalId":188691,"journal":{"name":"ACM SIGPLAN Symposium/Workshop on Haskell","volume":"2 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2007-09-30","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"114339337","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}
In this demonstration, we present an implementation of a modular synthesizer in Haskell using Yampa. A synthesizer, be it a hardware instrument or a pure software implementation, as here, is said to be modular if it provides sound-generating and sound-shaping components that can be interconnected in arbitrary ways. Yampa, a Haskell-embedded implementation of Functional Reactive Programming, supports flexible construction of hybrid systems. Since music is a hybrid continuous-time and discrete-time phenomenon, Yampa and is a good fit for such applications, offering some unique possibilities compared to most languages targeting music or audio applications. The demonstration illustrates this point by showing how simple audio blocks can be described and then interconnected in a network with dynamically changing structure, reflecting the changing demands of a musical performance.
{"title":"Demo outline: switched-on yampa","authors":"George Giorgidze, H. Nilsson","doi":"10.1145/1291201.1291213","DOIUrl":"https://doi.org/10.1145/1291201.1291213","url":null,"abstract":"In this demonstration, we present an implementation of a modular synthesizer in Haskell using Yampa. A synthesizer, be it a hardware instrument or a pure software implementation, as here, is said to be modular if it provides sound-generating and sound-shaping components that can be interconnected in arbitrary ways. Yampa, a Haskell-embedded implementation of Functional Reactive Programming, supports flexible construction of hybrid systems. Since music is a hybrid continuous-time and discrete-time phenomenon, Yampa and is a good fit for such applications, offering some unique possibilities compared to most languages targeting music or audio applications. The demonstration illustrates this point by showing how simple audio blocks can be described and then interconnected in a network with dynamically changing structure, reflecting the changing demands of a musical performance.","PeriodicalId":188691,"journal":{"name":"ACM SIGPLAN Symposium/Workshop on Haskell","volume":"67 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2007-09-30","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"114245173","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 present Harpy, a Haskell library for run-time code generation of x86 machine code. Harpy provides efficient generation of machine code, a convenient domain specific language for generating code and a collection of code generation combinators.
{"title":"Harpy: run-time code generation in haskell","authors":"Martin Grabmüller, Dirk Kleeblatt","doi":"10.1145/1291201.1291214","DOIUrl":"https://doi.org/10.1145/1291201.1291214","url":null,"abstract":"We present Harpy, a Haskell library for run-time code generation of x86 machine code. Harpy provides efficient generation of machine code, a convenient domain specific language for generating code and a collection of code generation combinators.","PeriodicalId":188691,"journal":{"name":"ACM SIGPLAN Symposium/Workshop on Haskell","volume":"124 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2007-09-30","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"116318259","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 Haskell programming language is more-or-less divided into two "branches". The Haskell 98 standard is the "stable" branch of the language, and that has been a big success. A lot of progress has been made over the last few years in the "research" branch of the Haskell language. It is constantly advancing, and we feel that it is time for a new standard which reflects those advancements. This talk is a status report from the Haskell' committee to the Haskell community.
{"title":"Haskell' status report","authors":"Isaac Jones","doi":"10.1145/1159842.1159860","DOIUrl":"https://doi.org/10.1145/1159842.1159860","url":null,"abstract":"The Haskell programming language is more-or-less divided into two \"branches\". The Haskell 98 standard is the \"stable\" branch of the language, and that has been a big success. A lot of progress has been made over the last few years in the \"research\" branch of the Haskell language. It is constantly advancing, and we feel that it is time for a new standard which reflects those advancements. This talk is a status report from the Haskell' committee to the Haskell community.","PeriodicalId":188691,"journal":{"name":"ACM SIGPLAN Symposium/Workshop on Haskell","volume":"69 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2006-09-17","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"128345878","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}
In languages that support polymorphic variants, a single variant value can be passed to many contexts that accept different sets of constructors. Polymorphic variants can be used in order to introduce extensible algebraic datatypes into functional programming languages and are potentially useful for application domains such as interpreters, graphical user interface (GUI) libraries and database interfaces, where the number of necessary constructors cannot be determined in advance. Very few functional languages, however, have a mechanism to extend existing datatypes by adding new constructors. In general, for polymorphic variants to be useful, we would need some mechanisms to reuse existing functions and extend them for new constructors.Actually, the type system of Haskell, when extended with parametric type classes (or multi-parameter type classes with functional dependencies), has enough power not only to mimic polymorphic variants but also to extend existing functions for new constructors.This paper, first, explains how to do this in Haskell's type system (Haskell 98 with popular extensions). However, this encoding of polymorphic variants is difficult to use in practice. This is because it is quite tedious for programmers to write mimic codes by hand and because the problem of ambiguous overloading resolution would embarrass programmers. Therefore, the paper proposes an extension of Haskell's type classes that supports polymorphic variants directly. It has a novel form of instance declarations where records and variants are handled symmetrically.This type system can produce vanilla Haskell codes as a result of type inference. Therefore it behaves as a preprocessor which translates the extended language into plain Haskell. Programmers would be able to use polymorphic variants without worrying nasty problems such as ambiguities.
{"title":"Polymorphic variants in Haskell","authors":"Koji Kagawa","doi":"10.1145/1159842.1159848","DOIUrl":"https://doi.org/10.1145/1159842.1159848","url":null,"abstract":"In languages that support polymorphic variants, a single variant value can be passed to many contexts that accept different sets of constructors. Polymorphic variants can be used in order to introduce extensible algebraic datatypes into functional programming languages and are potentially useful for application domains such as interpreters, graphical user interface (GUI) libraries and database interfaces, where the number of necessary constructors cannot be determined in advance. Very few functional languages, however, have a mechanism to extend existing datatypes by adding new constructors. In general, for polymorphic variants to be useful, we would need some mechanisms to reuse existing functions and extend them for new constructors.Actually, the type system of Haskell, when extended with parametric type classes (or multi-parameter type classes with functional dependencies), has enough power not only to mimic polymorphic variants but also to extend existing functions for new constructors.This paper, first, explains how to do this in Haskell's type system (Haskell 98 with popular extensions). However, this encoding of polymorphic variants is difficult to use in practice. This is because it is quite tedious for programmers to write mimic codes by hand and because the problem of ambiguous overloading resolution would embarrass programmers. Therefore, the paper proposes an extension of Haskell's type classes that supports polymorphic variants directly. It has a novel form of instance declarations where records and variants are handled symmetrically.This type system can produce vanilla Haskell codes as a result of type inference. Therefore it behaves as a preprocessor which translates the extended language into plain Haskell. Programmers would be able to use polymorphic variants without worrying nasty problems such as ambiguities.","PeriodicalId":188691,"journal":{"name":"ACM SIGPLAN Symposium/Workshop on Haskell","volume":"22 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2006-09-17","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"131900841","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 introduce the new, improved version of the Haskell Equational Reasoning Assistant, which consists of an Ajax application for rewriting Haskell fragments in their context, and an API for scripting non-trivial rewrites.
{"title":"Introducing the Haskell equational reasoning assistant","authors":"Andy Gill","doi":"10.1145/1159842.1159856","DOIUrl":"https://doi.org/10.1145/1159842.1159856","url":null,"abstract":"We introduce the new, improved version of the Haskell Equational Reasoning Assistant, which consists of an Ajax application for rewriting Haskell fragments in their context, and an API for scripting non-trivial rewrites.","PeriodicalId":188691,"journal":{"name":"ACM SIGPLAN Symposium/Workshop on Haskell","volume":"10 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2006-09-17","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"115042353","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
扫码关注我们
求助内容：
应助结果提醒方式：