Re: Choosing a language for compiler design

William D Clinger <will@ccs.neu.edu>
24 Oct 1996 22:21:55 -0400

          From comp.compilers

Related articles
[4 earlier articles]
Re: Choosing a language for compiler design icedancer@ibm.net (1996-10-18)
Re: Choosing a language for compiler design bmd@cs.kuleuven.ac.be (Bart Demoen) (1996-10-20)
Re: Choosing a language for compiler design jsa@alexandria.organon.com (1996-10-20)
Re: Choosing a language for compiler design jsa@alexandria.organon.com (1996-10-20)
Re: Choosing a language for compiler design joshua@intrinsa.com (Joshua Levy) (1996-10-20)
Re: Choosing a language for compiler design pbrisset@apoge.eis.enac.dgac.fr (Pascal Brisset) (1996-10-24)
Re: Choosing a language for compiler design will@ccs.neu.edu (William D Clinger) (1996-10-24)
Re: Choosing a language for compiler design rgh@shellus.com (1996-11-01)
Re: Choosing a language for compiler design geraldo@nw.com.br (1996-11-05)
| List of all articles for this month |

From: William D Clinger <will@ccs.neu.edu>
Newsgroups: comp.compilers
Date: 24 Oct 1996 22:21:55 -0400
Organization: Northeastern University
References: 96-10-075 96-10-083
Keywords: courses, design

In most of the last 8 years I have allowed students some choice of the
programming language in which they implement their compiler projects.
I can confirm Ken Walter's observation that there is "very little
difference in the time, size or problems" among student's compilers
written in most Fortran-like languages: C, Pascal, Modula-2, and so
forth.


I have seen a couple of very nice and compact student compilers
written in C++. On the other hand, most students who have chosen C++
have had an unusually rough time and have written ugly, bloated code.
I think most had learned C++ on their own and didn't understand it
very well.


Students who use Standard ML, Scheme, or Common Lisp usually submit
source code that is about 1/3 smaller than code written in the more
Fortran-like languages. I don't know whether they also spend less
time or have fewer problems.


Peter Sestoft (sestoft@ellemose.dina.kvl.dk) wrote:
> (Standard) ML...
> offers algebraic datatypes and polymorphic typechecking, so you'll
> have to suffer neither the C `segmentation fault' nor the Lisp `cannot
> take car of nil' messages.


Taking the "car of nil", or the head of the empty list, is a dynamic
exception, not a static type error, so students may still encounter
run-time error messages like "uncaught exception Hd" (in Standard ML
of New Jersey v0.93). The compiler can help some by warning of
nonexhaustive matches.


William D Clinger
--


Post a followup to this message

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