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
overhead of GC in caml runtime?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2000-08-08 (21:10)
From: Pierre Weis <Pierre.Weis@i...>
Subject: Re: Imperative programming in Caml
Hi Walid

> > If you write:
> > 
> > imperative call;
> > let x = blah in
> >   imperative call
> > 
> > then you get a little distracted by the indentation.  
> Got it!
> > Mmm.  I don't think you're going to have much success at showing that
> > O'Caml is a reasonable language without using at least some
> > polymorphism.  Perhaps this restatement of my previous code would
> > help, though:
> > 
> > type optional_int =
> >        | No_Int
> >        | Some_Int of int
> I feel you were "righter" the first time.  An "option" type is somehow
> semanticaly implict in having "null/nill" in every pointer.  So, I think
> it is reasonable to interpreter "'a pointer" as "'a option ref".  This
> also suggests a naturally way to translate imperative programs to
> functional programs systematically.
> Thanks again for the great feedback.
> Walid.

Your problem seems to have something to do with elementary programming
in Caml; you may have a look at the documentation, in particular the
FAQ where basic indentation hints are given in the programming guide
lines (http://pauillac.inria.fr/caml/FAQ/pgl-eng.html), and questions
about imperative programming in Caml including the existence of
imperative pointers and their encoding in Caml are discussed in
details (http://pauillac.inria.fr/caml/FAQ/pointers-eng.html).

Note: if you really do not want to use any kind of polymorphism, I'm
afraid you will have a bad time to write and explain imperative
programming examples in Caml, since you cannot use references ('a
ref), nor arrays ('a array), nor options ('a option), nor lists ('a
list); if you also consistently banish polymorphism from your function
type schemes, what could you do without the basic predicates such that
(=) (that has type 'a -> 'a -> bool), or even any comparison
predicates (<, <=, <>, ...)  that are also polymorphic ?

Hope this helps,

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://cristal.inria.fr/~weis/