Re: Compiler writers will love this language

ericmuttta@email.com (Eric) writes:




> So then, according to your experience, what are your guidelines? The
> kind of answers am looking for are in this form:
>
> *if you decide to have _____ then make sure you have/dont have ____
> due to the way they interact when mixed together


Don't mix unspecified evaluation order with unrestricted side-effects,
such that the result of a computation may depend on the (unknown)
evaluation order.


If you have pointers with less-than comparison and arithmetic (adding
offsets to pointers or subtract pointers to find a distance), make it
illegal (or at least undefined) to compare/subtract two pointers that
are not derived on the same base pointer (i.e, pointers into the same
array or struct).


> * you can include feature _____, its useful and easy to implement


Many things come to mind. Look at SML for a lot of features that are
nice and (relatively) easy to implement, e.g., higher order functions,
inductive data types with pattern matching, polymorphism, type
inference, a good module system, etc.


> * keep in mind that ____ is harder to implement than ____ but they do
> the same/similar thing


OO with dynamic dispatch is harder to implement than polymorphism
combined with type-classes (as in Haskell), but the latter is just as
useful (maybe more).


> * stay away from ____ its not worth the trouble unless you need ____


Mutual inheritance (unless static).


> * look at the grammar for language _____ , its easier/harder to
> implement because it does/doesn't have _____


Symbol-table dependent parsing, i.e., completely different paring
depending on whether a symbol is a type name, a variable name or a
class name. C++ is the prime horror story here, with so many
context-dependent rules that no parser for C++ is strictky conforming
to the standard.


> * language ___ does ____ in this way, but it would be better to do it
> like ____ because then we would implement it using _____


Many languages implicitly assume that all pointers can be null
pointers. It is better to distinguish this through the type, so you
can avoid testing for null pointers when the type ensures it can't
happen. Ideally, you would have subtyping, so a non-null pointer can
be passed to a function that expects a possibly-null pointer.


> * _____ is better kept in the language because then I can do ____ to
> optimize


Memory allocation, because I have free choice of GC or similar.


> * but _____ should go in libraries rather than the language because of
> _____


i/o, because there are so many variants of how it is done.


> Ps: I am interested in programming language design and compiler
> writing. I know more about the former than the latter, hence this
> post. I am also reading the classic text: "Compilers: Principles,
> Tools and Techniques" by Aho, Sethi and Ullman.


That book is good, but a bit dated. I propose that you supplement
this with a more modern text. Good choices are


  - Andrew Appels "Modern Compiler Implementation in ML/C/Java" (3
      books, mainly differing in which language is used to describe
      implementation details)


  - "Modern Compiler Design" by Grune, Bal, Jacos and Langendoen.


Alas, I know of no good book covering language design. Most modern
langauges have articles by the designers, presenting the reason behind
some of the design choices. These are a good place to start. You
should also read John Hughes' article "Why Functional Programming
Matters".


Torben Mogensen

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