Re: Implementation Language Choice

torbenm@diku.dk (Torben Ęgidius Mogensen)
6 Mar 2004 14:01:28 -0500

          From comp.compilers

Related articles
[6 earlier articles]
Re: Implementation Language Choice lex@cc.gatech.edu (Lex Spoon) (2004-02-26)
Re: Implementation Language Choice joachim.durchholz@web.de (Joachim Durchholz) (2004-02-26)
Re: Implementation Language Choice gdr@integrable-solutions.net (Gabriel Dos Reis) (2004-02-27)
Re: Implementation Language Choice joachim.durchholz@web.de (Joachim Durchholz) (2004-03-02)
Re: Implementation Language Choice la@iki.fi (Lauri Alanko) (2004-03-02)
Re: Implementation Language Choice lex@cc.gatech.edu (Lex Spoon) (2004-03-02)
Re: Implementation Language Choice torbenm@diku.dk (2004-03-06)
Re: Implementation Language Choice bettini@dsi.unifi.it (Lorenzo Bettini) (2004-03-06)
Re: Implementation Language Choice joachim.durchholz@web.de (Joachim Durchholz) (2004-03-11)
Re: Implementation Language Choice mayan@sandbridgetech.com (Mayan) (2004-03-19)
Re: Implementation Language Choice Barak.Zalstein@ceva-dsp.com (Barak Zalstein) (2004-03-26)
| List of all articles for this month |

From: torbenm@diku.dk (Torben Ęgidius Mogensen)
Newsgroups: comp.compilers
Date: 6 Mar 2004 14:01:28 -0500
Organization: Department of Computer Science, University of Copenhagen
References: 04-02-109 04-02-131 04-02-149 04-02-164 04-03-017
Keywords: functional
Posted-Date: 06 Mar 2004 14:01:28 EST

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


Post a followup to this message

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