RE: [Caml-list] let mutable (was OCaml Speed for Block Convolutions)

["Dave Berry" <Dave@kal.com>]

Let me refute my own suggestion.  If people do want the ability to
specify stack allocation, they will want it for immutable values as well
as mutable values.  So it should be a separate, orthogonal construct.


-----Original Message-----
From: Dave Berry 
Sent: 08 June 2001 10:00
To: Jacques Garrigue; tom7ca@yahoo.com
Cc: williamc@paneris.org; caml-list@inria.fr
Subject: RE: [Caml-list] let mutable (was OCaml Speed for Block
Convolutions)


One possible reason for adding "let mutable" would be to specify that
escapes (such as the one Jacques gave) are explicitly disallowed.  In
other words, programmers could use "let mutable" to enforce the
requirement that the data is stack-allocated.  The compiler would report
an error if it is not possible to stack-allocate, instead of silently
defaulting to heap allocation.  Programmers might want to do this to
guarantee efficiency, or to guarantee that the memory is deallocated and
does not become a potential memory leak.

It might even be possible to attach finalisers to the data, which would
be guaranteed to be called when the function exits, analogous to C++
destructors.  However, this would complicate exception handling and
possibly tail-recursion optimisations.


-----Original Message-----
From: Jacques Garrigue [mailto:garrigue@kurims.kyoto-u.ac.jp]
Sent: 08 June 2001 00:50
To: tom7ca@yahoo.com
Cc: williamc@paneris.org; caml-list@inria.fr
Subject: [Caml-list] let mutable (was OCaml Speed for Block
Convolutions)


About the introduction of a let mutable construct,
Tom _ <tom7ca@yahoo.com> wrote

> In any case, whether or not the compiler in the
> current implementation can or cannot do good type
> inference and may or may not be forced to box
> a floating point number, the two constructs mean
> something different to the programmer, and they
> behave differently.  In particular "mutable x"
> can never be passed around as a reference, while
> "x = ref ..." can.  If not anything else, that
> prevents the programmer from inadvertently inhibiting
> a compiler optimization by passing around a reference.

Not exactly, the compiler may still need to build a reference.

    let mutable x = 0 in
    List.iter (fun y -> x <- x+y) l;
    x

Since x has to be modified in a function called by iter, it must be
wrapped into an actual reference cell.

As the compiler already does a good job at unboxing only locally used
references, let mutable would only be some syntactic sugar (with
exactly the same typing as a reference).

> Besides, the syntax is probably quite a bit more 
> natural to imperative programmers anyway.

This is actually the only argument for let mutable.
I would also like such a construct, but I don't know whether its worth
it. The real question is whether let mutable should be allowed at
toplevel, with problems for both answers.

Cheers,

Jacques Garrigue
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ:
http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives:
http://caml.inria.fr
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ:
http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives:
http://caml.inria.fr
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr