Results 1 
4 of
4
Reflections on Standard ML
 FUNCTIONAL PROGRAMMING, CONCURRENCY, SIMULATION AND AUTOMATED REASONING, VOLUME 693 OF LNCS
, 1992
"... Standard ML is one of a number of new programming languages developed in the 1980s that are seen as suitable vehicles for serious systems and applications programming. It offers an excellent ratio of expressiveness to language complexity, and provides competitive efficiency. Because of its type an ..."
Abstract

Cited by 198 (4 self)
 Add to MetaCart
Standard ML is one of a number of new programming languages developed in the 1980s that are seen as suitable vehicles for serious systems and applications programming. It offers an excellent ratio of expressiveness to language complexity, and provides competitive efficiency. Because of its type and module system, Standard ML manages to combine safety, security, and robustness with much of the flexibility of dynamically typed languages like Lisp. It is also has the most welldeveloped scientific foundation of any major language. Here I review the strengths and weaknesses of Standard ML and describe some of what we have learned through the design, implementation, and use of the language.
Operational Semantics and Polymorphic Type Inference
, 1988
"... Three languages with polymorphic type disciplines are discussed, namely the *calculus with Milner's polymorphic type discipline; a language with imperative features (polymorphic references); and a skeletal module language with structures, signatures and functors. In each of the two first cases we ..."
Abstract

Cited by 92 (2 self)
 Add to MetaCart
Three languages with polymorphic type disciplines are discussed, namely the *calculus with Milner's polymorphic type discipline; a language with imperative features (polymorphic references); and a skeletal module language with structures, signatures and functors. In each of the two first cases we show that the type inference system is consistent with an operational dynamic semantics. On the module level, polymorphic types correspond to signatures. There is a notion of principal signature. Socalled signature checking is the module level equivalent of type checking. In particular, there exists an algorithm which either fails or produces a principal signature.
A Runtime System
, 1990
"... The runtime data structures of the Standard ML of New Jersey compiler are simple yet general. As a result, code generators are easy to implement, programs execute quickly, garbage collectors are easy to implement and work efficiently, and a variety of runtime facilities can be provided with ease. ..."
Abstract

Cited by 64 (3 self)
 Add to MetaCart
The runtime data structures of the Standard ML of New Jersey compiler are simple yet general. As a result, code generators are easy to implement, programs execute quickly, garbage collectors are easy to implement and work efficiently, and a variety of runtime facilities can be provided with ease.
Tree Pattern Matching for ML (Extended Abstract)
, 1985
"... This paper addresses the problem of compiling such sequences of patterns into efficient patternmatching code. The goal is to minimize the number of tests or discriminations that have to be applied to any given argument to determine the first pattern it matches. Our approach is to transform a sequen ..."
Abstract

Cited by 5 (0 self)
 Add to MetaCart
This paper addresses the problem of compiling such sequences of patterns into efficient patternmatching code. The goal is to minimize the number of tests or discriminations that have to be applied to any given argument to determine the first pattern it matches. Our approach is to transform a sequence of patterns into a decision tree, i.e. a tree which encodes the patterns and defines the order in which subterms of any given value term have to be tested at runtime to determine which pattern matches the value. Each internal node of a decision tree corresponds to a matching test and each branch is labeled with one of the possible results of the matching test and with a list of the patterns which remain potential candidates in that case. It is then straightforward to translate the decision tree into code for pattern matching. During the construction of a decision tree it is also easy to determine whether the pattern set is "exhaustive", meaning every possible argument value matches at least one pattern, and whether there are any "redundant" patterns (i.e. patterns that are matched only by values that are already matched by an earlier pattern). Nonexhaustive definitions and redundant patterns are anomalies that can be  2  usefully reported by the compiler. Our goal in constructing the decision tree is simply to minimize the total number of testnodes. This minimizes the size of the generated code and also generally minimizes the number of tests performed on value terms. However, we have discovered that finding the decision tree with the minimum number of nodes is an NPcomplete problem. This result is established by reduction from one of the trie index construction problems (pruned Otrie space minimization), which was proved to be NPcomplete in [Co76, CS77]. Therefore...