© Jørgen Steensgaard-Madsen, Copenhagen, 2006
Design issues                                                  
 
   

A design space restricts a designer's possible choices. For a programming language designer, it may be nice to know early on if only typed languages can be designed. Characterising a particular design space is an abstract activity, so an illustration by examples has been preferred although examples do not set general limits. The examples are drawn from an early, small demonstration language.
Commands will be typechecked, but users will in general not be bothered with types - they appear only in error messages and are required in definitions that supports new terms and operators.
An expression will be a sequence of alternating terms and operators. Two terms written next to each other are connected by the special optional operator. Operators are binary, but either the left or the right operand may be absent. (New users are recommended to use parentheses in situations where two operators would otherwise be next to each other as well as around a left, non-constant operand of the optional operator.)
A term is a name followed by a sequence of clauses. The sequence must have a fixed length for a specific name. Every clause can be a semicolon separated list of expressions enclosed in braces. A comma separated list of expressions enclosed in parentheses is equivalent to a list of clauses. The two lists have the same length and each clause contains, of course, the corresponding element from the comma separated list of expressions.
Howard languages relies on a notation for abstract syntax and on conventions for concrete expressions. It implies that the same program may be expressed in several ways to please the programmer's taste, e.g 
if (a<10) then {stdout<<a} else {stdout<<b}
if (a<10,stdout<<a,stdout<<b)
These are identical in the abstract and both are allowed by the notational conventions. The << operator indicates writing, so the expressions above differ from
stdout<<if(a<10,a,b)
although they may have the same behaviour. Note that the latter is in error, when the types of a and b differ, whereas the former should be fine.
Like ML, languages implemented with dulce are strongly typed. Types originate with native operations, so types can be introduced in one of two ways:
  1. Predefined type operators are named in the abstract syntax, i.e. they are visible everywhere in a program

  2. In an object-oriented like manner abstract type operators may be perceived as `members' required to describe operations with results from new types.

Type operators play an important rôle in the description of operations, but are suppressed as much as possible in the user interface: users are not told (by default) what type a computed result has. Types are expressions in type operators (using reverse Polish notation as in ML).
Operations may be polymorphic, i.e. an operation may be (partly) independent of the type of some required arguments, as for instance the length of a list is independent of the type of elements in the list. This is as in ML. However, use of an operation may also introduce a new type constructor, hence to some extent similar to use of a functor in ML. There is no distinction between functors and functions in Howard languages.
Type inference is used for many ML-like languages. Explicitly typed descriptions are used as the abstract syntax of operations, and interpreters match actual use of operations against their descriptions. This allows for non-shallow polymorphism in contrast to ML-like languages.
Essentially, type analysis is unification for both Howard languages and ML-like languages. A subtle difference in approach exists: in a Howard language a polymorphic operation is one that expects a type as an operand, but type analysis allows users to omit it; whereas polymorphic operations in ML-like languages expect no type operand. Thus it will be better to use the term type completion for the analysis in dulce-interpreters.
Having type completion, one may ask if completion might be useful for other kinds of arguments. An affirmative answer is given with the dulce-interpreters: some operator meanings may depend on other meanings that can be supplied automatically. Detailed examples will be given later, so suffice it to mention equality tests: comparing two lists implies compairing elements, i.e. another meaning of the same operator symbol. The ML-like language Haskell uses an approach to this problem that differs from ours.
Types are essential to discern among different meanings associated with a particular operator symbol.

Contents

Demo language
·Implementation tool
Copyrights


Introduction
·Principles
Interpreter construction


Deep- and surface structures
·Design issues
Abstract type operatorss
Description of operator
Name introduction
Data abstraction and control



File translated from TEX by TTH, version 3.33.
On 18 Oct 2006, 16:47.
SourceForge.net Logo