The C programming language
Simple imperative polymorphism
Lisp and Symbolic Computation - Special issue on state in programming languages (part I)
What are principal typings and what are they good for?
POPL '96 Proceedings of the 23rd ACM SIGPLAN-SIGACT symposium on Principles of programming languages
Proceedings of the ACM SIGPLAN 1999 conference on Programming language design and implementation
The Definition of Standard ML
High-level views on low-level representations
Proceedings of the tenth ACM SIGPLAN international conference on Functional programming
Quantified types in an imperative language
ACM Transactions on Programming Languages and Systems (TOPLAS)
SysObjC: C extension for development of object-oriented operating systems
Proceedings of the 3rd workshop on Programming languages and operating systems: linguistic support for modern operating systems
Proceedings of the 3rd workshop on Programming languages and operating systems: linguistic support for modern operating systems
Sound and Complete Type Inference for a Systems Programming Language
APLAS '08 Proceedings of the 6th Asian Symposium on Programming Languages and Systems
Hi-index | 0.00 |
Systems programs rely on fine-grain control of data representation and use of state to achieve performance, conformance to hard-ware specification, and temporal predictability. The robustness and checkability of these programs could be greatly improved if modern type systems and programming language ideas, such as polymorphism and type inference, could be applied to these programs.BitC is a higher-order programming language in the tradition of ML and Haskell, extended to incorporate both state and the expression of unboxed and low-level datatypes. State and unboxed value types interact in subtle ways with polymorphic type-inference. Unless handled with care in the language design, interactions of these features can lead to unsoundness or results that are counter-intuitive to the programmer. Because instances of value types may have mutable components, a decision must be made concerning their compatibility at copy boundaries: should structurally equivalent types that differ only in their mutability be considered compatible. The choice impacts both the amount of polymorphism that the language can preserve and the burden of type annotation imposed on the programmer.This paper presents some of these challenges and our design for how to address these issues.