Re: Implementation Language Choice

Lex Spoon <lex@cc.gatech.edu> writes:


> Joachim Durchholz <joachim.durchholz@web.de> writes:
>
> > Lex Spoon wrote:
> >> The feature that is especially nice is the pattern-matching switch
> >> statement that most functional languages include.
> >
> > Though it's beyond me why this never made it into mainstream imperative
> > languages; it's exceedingly useful.
>
> Most languages seem to allow defining new variants in different parts
> of the code. For example, an OO language will let you make new
> subclasses at other parts of the code. This makes it harder to define
> and to compile (see, on topic!) the case construct.
>
> Also, there is a downside in that you are decomposing the *concrete
> represenation*. Many languages -- and especially OO languages --
> treat this as a breach of encapsulation and try to prevent it.


This is only partly true: A compiler has some freedom in how the
datatype is implemented. However, I agree that it pattern-matching is
usually restricted to a single datatype (apart from polymorphism on
some fields).


This need, however, not be true. You can use Haskell-style type
classes to declare several types as instances of a type-class that use
a particular set of patterns by letting each type implement a selector
and a set of functions that provide the values bound in the pattern.
This is similar to the "views" mechanism proposed by Wadler many years
ago.


This need not be notationally cumbersome. You can let a datatype
declaration (which in Haskell-parlance means a set of constructors)
double as a type-class declaration with a default instance (which is
the concrete datatype) but allow other types to define other instances
of the same type-class.


However, in the case of abstract syntax, I don't really see much need
to hide the implementation.


The addition of new constructs to a language by extending the abstract
is more relevant and not as obvious to solve. The usual solution is
to find every place where pattern-matching is made on the syntax and
add new cases. This is not as bad as it sounds, as the type-checker
can identify the places where it is needed. And while separating each
syntactic construct into different parts of the program might seem to
aid modularity, it can make it difficult to understand the program.


Torben

Return to the comp.compilers page.
Search the comp.compilers archives again.