Re: Why ML/OCaml are good for writing compilers

Valentin Bonnard <>
16 Aug 1998 22:48:57 -0400

          From comp.compilers

Related articles
Why ML/OCaml are good for writing compilers (1998-07-28)
Re: Why ML/OCaml are good for writing compilers (Tony Bass) (1998-07-30)
Re: Why ML/OCaml are good for writing compilers amitp@Theory.Stanford.EDU (Amit Patel) (1998-08-13)
Re: Why ML/OCaml are good for writing compilers (Chris F Clark) (1998-08-16)
Re: Why ML/OCaml are good for writing compilers (Valentin Bonnard) (1998-08-16)
| List of all articles for this month |

From: Valentin Bonnard <>
Newsgroups: comp.compilers
Date: 16 Aug 1998 22:48:57 -0400
Organization: Ecole Normale Superieure, Paris, France
References: 98-07-220 98-08-093
Keywords: C++, practice (Dwight VandenBerghe) writes:
> [snip]
> > So here is an unordered list of language features that seems to me
> > to make writing compilers a pleasure rather than a horrendous chore.
> [many things snipped]
> > So it's mostly about data structures. ML is extraordinarily
> > facile at allowing you to express complex data structures and
> > recursive algorithms around them. The most basic data structures
> > (lists, arrays, structs, unions, property lists, hash tables,
> > binary trees, queues, and so on) are sitting there in the
> > language already, well-implemented and ready to go.

C++ also has vector, list, stack, map (associative array), set,
deque. That's doesn't make it the ideal language for writing compilers

Amit Patel <amitp@Theory.Stanford.EDU> writes:
> Some time later, I looked at what C
> compiler code looked like, and I was *shocked*. It was incredibly
> ugly in comparison to what I had seen in ML. The compiler I saw was
> using a tree structure with child and right pointers, and if you
> wanted to access (for example) the 'else' part of an IF statement,
> you'd do something like:
> if(node->type==IF) {
> Node* else_part = node->child->right->right; /* EWWWWWW */
> }

That's bad C programming.

It should be:

if(node->type==IF) {
    Node* else_part = node.if_type->else_part;

which is much better. In C++ you could write:

        Node* else_part = node.if_type()->else_part;

where if_type() throws if for ex. node is actually a switch.

> ML's data structures (tagged unions) are *perfect* for representing
> abstract syntax trees, but I think pattern matching is the real win
> here.

Yes, but unification is still missing:

fun Mult(x,x) -> Square x
    | other -> other

Valentin Bonnard
info about C++/a propos du C++:

Post a followup to this message

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