RE: [Caml-list] ocaml sefault in bytecode: unanswered questions

["ivan chollet" <ivan.chollet@free.fr>]

Hello David,

I was just saying that because Edgar seemed to imply that "let l = !myref in List.iter myfun l" behaved differently than "List.iter myfun !myref" but you think they behave the same. 
It's fine for me.

Thanks!

-----Original Message-----
From: David Allsopp [mailto:dra-news@metastack.com] 
Sent: samedi 8 août 2009 19:15
To: 'ivan chollet'; 'Edgar Friendly'
Cc: caml-list@yquem.inria.fr
Subject: RE: [Caml-list] ocaml sefault in bytecode: unanswered questions

Apologies if I'm missing something obvious (I had a good lunch)...

Ivan Chollet wrote:
> Yes, makes sense. But it would mean that "List.iter myfun !myref" is
> not semantically equivalent to "List.iter myfun (let l=!myref in l)",

How does this follow from Edgar's explanation? (below)

> therefore the expressions "let l=!myref in l" and "!myref" are not
> semantically equivalent.

These expressions are semantically equivalent: the former merely (locally) aliases the name [l] to the result [!myref] before returning it. Aliasing a value is not the same as allocating memory. For example:

let a = "1" in
let b = a;;

Results in one allocation (a value containing the string "1") and one aliasing of the name [b] to represent the same value.

So, considering your example, observe:

let myref = ref [1; 2] in
let l = !myref in
l == !myref;;

which is [true]. [l] and [!myref] are physically the same value - i.e. the [let l] expression did not result in an allocation.

Ivan Chollet previously wrote:
> Why? It would mean that doing "let l = !myref" creates a brand new OCaml entity, l, ie a brand new 
> allocation on the heap, and then, messing around with !myref inside myfun would be of course 100% safe. 

Two problems: firstly, let l = !myref does not result in an allocation (because [l] is simply an alias for the contents of myref at the time of the [let]). Secondly, you cannot mess around with !myref - the content of a reference is immutable, it is only the reference itself which can be changed (notwithstanding 'a ref ref and so on). Once you said [List.iter myfun !myref], you pass the contents of [myref] to [List.iter] and [myfun] can do whatever it likes with the *reference* [myref] without affecting those contents at that point and so the processing of [List.iter].

Do you have an actual case which segfaults?

HTH,


David 

> 
> That would be very strange!
> 
> 
> -----Original Message-----
> From: Edgar Friendly [mailto:thelema314@gmail.com]
> Sent: samedi 8 août 2009 15:29
> To: ivan chollet
> Cc: 'Cedric Auger'; caml-list@yquem.inria.fr
> Subject: Re: [Caml-list] ocaml sefault in bytecode: unanswered
> questions
> 
> ivan chollet wrote:
> > You basically state that stuff like “let l = !myref in List.iter
> myfun l”
> > (where myfun modifies !myref) wouldn't produce segfault.
> > Why? It would mean that doing "let l = !myref" creates a brand new
> OCaml
> > entity, l, ie a brand new allocation on the heap, and then, messing
> around
> > with !myref inside myfun would be of course 100% safe. Is that what
> OCaml
> > runtime does?
> 
> when you have [myref : list ref = ref [1;2]], this is in memory as:
> 
> myref -> {contents: _a}
> _a -> (1,_b)
> _b -> (2,0)
> 
> I've given names to the intermediate pointers -- the notation above
> shows names as pointers to data structures.  [myref] is a pointer to a
> record, whose contents point to the head of the list [1;2].  So there's
> already two levels of indirection.
> 
> When you do [let l = !myref], [l] gets assigned [_a], so it points to
> the head of the list.  List.iter traverses the list not even knowing
> that [myref] exists, so if the function [myfun] modifies [myref], it
> won't affect List.iter.
> 
> Does this make sense?
> 
> E
> 
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs