Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] look operator
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Winfried Dreckmann <wd@l...>
Subject: Re: [Caml-list] look operator
on 06.06.2002 12:58 Uhr, Pixel at pixel@mandrakesoft.com wrote:

> => "look" is only used for efficiency? couldn't the compiler achieve
> the same result without using an unsafe construct?

Yes, only for efficiency, see Michel Quercia's reply. As you point out,
there are other ways to do the same thing which are safe but cost too much.

>> Using "look", every single
>> function with arguments of type t, say
>> 
>> val add_in : tref -> t -> t -> unit,
>> 
>> replaces two or more functions which would otherwise be necessary, in this
>> case
>> 
>> val add_in1 : tref -> t -> t -> unit
>> val add_in2 : tref -> tref -> t -> unit
>> val add_in3 : tref -> tref -> tref -> unit
> 
> are you saying that i would be nice to have this? As far as i have
> looked at numerix, it doesn't have this.

No, I'm saying that "add_in" together with "look" has the same functionality
as the three functions below. I find this quite elegant, if there were no
safety issues with "look".

>> My question to the caml list: Would you accept such constructions as decent
>> Caml programming, if applied carefully and only in cases where it allows
>> what is otherwise impossible (e. g. integrating mutable and non-mutable
>> objects as it is done in "numerix"). Or is it all just a silent
>> reintroduction of C pointers, and principally a bad thing?
> 
> I don't think this will never be in OCaml!
> (but i may be prooved wrong :)

Right so! But with the C interface you can program such constructions
anyway. I wouldn't see a problem at all if all unsafety is hidden from the
user. However, in the case of "look" in the "numerix" library a certain
amount of unsafety is left to the user. This is unsatisfactory. Michel
Quercia describes some ideas to solve this problem in his letter.

Thanks for the link.

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