Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] productivity improvement
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Eray Ozkural <erayo@c...>
Subject: Re: [Caml-list] Re: productivity improvement
On Friday 18 October 2002 00:27, Dave Berry wrote:
> >For a C++ compiler, the ratio would be about the same since C++ has
> > simpler semantics but a more involved syntax than well designed
> > languages.
> I'm staggered at your suggestion that C++ has a simple semantics.  To me, a
> major advantage of the ML family is that their semantics is relatively
> simple.

C++ has a less sophisticated and mathematically lacking semantics devoid of 
generality compared to ML family, especially modern incarnations such as 

The hard part of writing a C++ compiler is coping with several syntactic 
ambiguities and incoherent semantics (such as in templates and type system) 
rather than realizing a well defined and expressive semantics.

Where in C++ is orthogonality, reliability, parametrized/recursive  types, 
parametrized modules, etc.? I'm staggered at you claiming more than C++ 
deserves. Where C++ ought to be strongest, OOP, ocaml is much more general 
and complete. In other design objectives ocaml beats C++ by a good measure. 
No derivative of C can be a really good programming language design and C++ 
is not an exception.

It isn't just a coincidence that programming language research focuses on 
functional languages a la ML.

And that the industry uses largely C++ has nothing to do with semantics. I 
think it is clear why the industry prefers one language over another; it is 
collective stupidity.

As a side note, once you get past the parsing stage it should be relatively 
easy to implement an optimizing C++ or C# compiler. I've been working on a 
C++ parser, but the syntax is so hard it's almost impossible to implement 
everything and verify that it really works. (Another indication that the 
design sucks) The syntactic analyzer itself could take a couple of thousands 
of lines. All in all it would still take 10000 or more lines. I would 
estimate somewhere about 10000-20000 lines for a C++ compiler. A C# compiler 
could be made smaller.

If we had a good C++ parser written in ocaml or haskell we could proceed to a 
full compiler very fast. It just hasn't been done before.

I can put forward a challenge in front of you and I think you would be much 
more helpless than I am about writing a C++ compiler from scratch -- which is 
no easy undertaking whatever the implementation language is. What about 
writing a full-fledged ocaml or haskell compiler in C++? I am pretty sure 
that would be an overwhelming task, something which would require more than 
100.000 lines of C++ code.

I intend to release a version of my parser when it is able to parse KDE 
headers. Maybe then people experienced in C++ parsers can work on a 
full-fledged compiler. I'm writing a top-down parser like in the recent 
versions of g++ using haskell Parsec library.


Eray Ozkural <>
Comp. Sci. Dept., Bilkent University, Ankara
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C
To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: