Re: [Caml-list] look operator

[Winfried Dreckmann <wd@lidingo.mail.telia.com>]

on 06.06.2002 17:08 Uhr, Michel Quercia at michel.quercia@prepas.org wrote:

> The "look" operation should be restricted to local use only, and the
> "copy_out" operation should be used whenever
> it can not be proved that r will never be modified again."

Thanks for your long explanations. I understand that you are concerned with
the safety problem.

> Right, and should such an operation become standard, then the compiler should
> check that the tref "r" becomes unreachable after the last "look" (this may be
> easier to say than to implement).

I think it's an interesting idea which one should keep in mind.

> I think overloading is absolutely necessary when dealing with numerical data.
> ...
> When such an overloading mechanism will be available, the "look" operation
> will disappear at the next Numerix release (but not the "trefs").

That would be the best solution. Not the "trefs" of course. Having t's and
tref's together is the best part.

>> I could, for instance, also imagine an abstract assign operator
>> 
>> val set : tref -> t -> unit
>> 
>> where the contents of t is not copied but assigned to tref, and thus made
>> mutable, which could be useful in certain restricted ways.
> 
> This is too dangerous :
>
> let e1 = ... and e2 = ... in
> set r (if ... then e1 else e2);
> xxx_in r ...;
>
> (* try and guess what will be e1 and e2 now *)

Definitely. Actually I was thinking about implementing matrices with mutable
entries where for efficiency reasons the implementation type of entries
would be t, and of course implementation details would be hidden by the
interface. To do this with Numerix one would at least need a function

val set : tref -> t matrix -> int -> int -> unit

to make matrix entries accessible to in-place operations (with an subsequent
update to make sure the entries get really changed). So I thought there is
more to "look" than "look", and that assignment operators are also worth
considering. But this is stretching it very far. In fact, the above way of
implementing matrices with mutable entries looks like a kind of unboxing,
and this may be best seen, according to Xavier Leroy, as an optimization.

Regards,
Winfried Dreckmann

-------------------
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/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners