caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Winfried Dreckmann <wd@lidingo.mail.telia.com>
To: Pixel <pixel@mandrakesoft.com>
Cc: "€ caml list" <caml-list@inria.fr>
Subject: Re: [Caml-list] look operator
Date: Fri, 07 Jun 2002 10:02:16 +0200	[thread overview]
Message-ID: <B9263527.B92B%wd@lidingo.mail.telia.com> (raw)
In-Reply-To: <lyu1oghdvx.fsf@leia.mandrakesoft.com>

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


  reply	other threads:[~2002-06-07  7:58 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-06-06 10:01 Winfried Dreckmann
2002-06-06 10:58 ` Pixel
2002-06-07  8:02   ` Winfried Dreckmann [this message]
2002-06-06 15:08 ` Michel Quercia
2002-06-07  9:13   ` Winfried Dreckmann
2002-06-07 13:52     ` Michel Quercia
2002-06-08 11:23       ` Winfried Dreckmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=B9263527.B92B%wd@lidingo.mail.telia.com \
    --to=wd@lidingo.mail.telia.com \
    --cc=caml-list@inria.fr \
    --cc=pixel@mandrakesoft.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).