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
Parameter evaluation order
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2005-08-26 (17:00)
From: Christophe Raffalli <christophe.raffalli@u...>
Subject: Re: [Caml-list] Re: Parameter evaluation order
Ville-Pertti Keinonen a écrit :

 > Christophe Raffalli wrote:
 >> Jon Harrop a écrit :
 >>> Semicolons are used in many places in OCaml's grammar. Would you 
expect the members of a list literal to be evaluated left-to-right, for 
 >> yes I would ...
 > An OCaml list is built starting with the tail.  Left-to-right 
evaluation could end up using huge amounts of temporaries.

This is the same problem as the problem of a tail recursive map 
function, which is important and has reasonable solution.
the only risk is to charge the grey vals list of the GC if the 
evaluation of the list elements allocates enough memory to move 
partially constructed cons cell to the major heap.

But yet I quite agree this is a good point ... but you just need to 
redefine list as

type 'a rlist = Cons of 'a rlist * 'a | Nil


anyway one of the data type list or rlist as an efficiency problem 
whatever evaluation order you choose.

May be the good evaluation order for variants is recursive arguments 
last ? Or one should let the user choose ?

It is strange to note that records are less problematic since you can 
permutte the field to choose yourself the evaluation order ...

may be variant should have only one argument and list should be

type 'a record_list = Cons of { car : 'a; cdr : 'a list } | Nil

 > Consider an explicit implementation of lists:
 > type 'a list = Cons of 'a * 'a list | Nil
 > Now, you'd write the list [ a; b; c; d ] (where a, b, c and d could 
be complex expressions) as
 > Cons (a, Cons (b, Cons (c, (Cons (d, Nil)))))
 > You need to have Cons (d, Nil) before you can construct Cons (c, ...) 
etc.  It's the innermost expression, so evaluating it first makes sense 
in any sensible evaluation order.