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] Does Caml have slow arithmetics ?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: skaller <skaller@u...>
Subject: Re: [Caml-list] Does Caml have slow arithmetics ?
On Thu, 2004-07-08 at 13:44, David Brown wrote:
> > Of course that argument fails totally in one important
> > case -- Q: if you wanted a loop why didn't you use one?
> > A: tail-rec functional code is considered cute :)
> In some functional languages (Scheme, specifically), tail recursion is
> required to be implemented iteratively.  It is a common enough idiom,
> and easy enough to implement, that it is generally done in functional
> languages.  In fact, gcc does it in C, with enough optimization.

I'm aware of this, my point is that Xavier's argument
that complex code generates inefficient code 
"what else do you expect?" is a bit weak.

Whether you expect tail-rec optimisation or not
depends on your knowledge of compiler implementation

Felix for example has a functional subsystem which
one could argue is "more functional" than Ocaml's
since side effects are not permitted .. but it happens
to generate C at the moment -- and I admit I myself
have no idea whether tail calls in functions are
optimised or not, or how to actually organise the generated
C so as to encourage a compiler .. perhaps gcc, perhaps MSVC ..
to actually perform the optimisation. Procedure calls ARE
tail-rec optimised by Felix (guarranteed!) but the calling
mechanism is quite different to that used for functions.

Even experts are often surprised by generated code complexity.
In C++ for example, the close connection between source
and generated code is lost in some cases, particularly
constructor calls: the cost of instantiating a class with
virtual bases and functions derived from others can be
extremely high and is silently hidden .. and C++ experts 
often miss the disparity between source and generated code.

Note I'm not disputing Xaviers orientation here: I basically
agree, I merely wish to point out that the argument isn't
quite as strong as one might think. Higher level optimisations
are also important IMHO. Chosing which ones to actually do
is of course very hard :)

John Skaller,
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language

To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: