Re: Why ML/OCaml are good for writing compilers

dwight@pentasoft.com (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
(IMHO).


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:


if(node->type==IF)
        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 mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://pages.pratique.fr/~bonnardv/
--

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