English version
Accueil     Ŕ propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis ŕ jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml ŕ l'adresse ocaml.org.

Browse thread
tail rec
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2007-05-19 (16:06)
From: skaller <skaller@u...>
Subject: Re: [Caml-list] tail rec
On Sat, 2007-05-19 at 16:46 +0200, Oliver Bandel wrote:

> > I think this is blocking understanding of how ressources
> > are allocated, when one uses a certain style of programming
> > and datastructures.
> Forget these words: I misunderstood your email,
> because I did not read until end before I answered.
> Sorry for the unnecessary traffic.

Actually you make an important point!

> I thought you want to automatically *convert*
> code to tailrec-code.

Well that would be totally cool, but it appears
to be a rather hard problem?

>  Even if this would
> also be a fine thing, it could block understanding,
> as mentioned above.

Actually, you DO have an important point here.
When looking at, say, ordinary Ocaml code,
it is important to learn about recursion.

Examining the syntactic structure of the code
to understand the 'different' uses of a simple
but powerful primitive in an 'idiomatic' way
is important for understanding functional programming.

The use of sugar, annotations, or other device to
assure certain properties may well hide these idioms,
making learning and recognizing them harder.

I say 'may' because I'm only one individual, and not
a teacher familiar with learning experiences of many people.

> But you only want to have warnings...
> ...that might be a good helper.

Actually no: if you write 

let tailrec ...

then if a direct call of f is not in tail position,
you get a hard error, not a warning.

The construction has definite semantics. That applies
to Basile's more local annotation too.

In both cases the error indicates either that the routine
is possibly suboptimal in performance, or even that there
is a semantic bug in it!

John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net