0005291: A not detected loop -> seg fault

(0007479)
frisch (developer)
2012-05-31 11:26

Even simpler:

class a = let _ = new a in object end
->
segfault

(0007480)
frisch (developer)
2012-05-31 11:29

Note: segfault is at execution time.

(0007483)
frisch (developer)
2012-05-31 18:56

Local let-binding in a class declaration are currently executed when the class declaration is evaluated, not when the object is created. I'm tempted to consider it is a design bug that:

class c = let () = print_endline "XXX" in object end

writes "XXX". With this current semantics, one should indeed restrict references to the class being defined. I.e. in

class c = let p = e in ....

the class c should not be visible in e. But I'd prefer fixing the semantics of let bindings...

(0007485)
garrigue (manager)
2012-06-01 05:13

This evaluation order is intentional.
It allows you to define values in an environment where class types are available.
Example:

class c =
let r = ref [] in
object (self) method friends = !r initializer r := (self :> c) :: !r end

If you put "let r = ref []" this definition goes through, but something strange
happens to your types...

If you want side-effects at object creation time, then your class should
take an argument, or should put them into a field.

(0007487)
frisch (developer)
2012-06-01 05:22

> If you want side-effects at object creation time, then your class should
take an argument, or should put them into a field.

.. or an initializer

So, we want the class to be available as a type, but not as a "value", i.e. we should disallow "new c" and "inherit c" in the body of let-binding, right?

(0007488)
garrigue (manager)
2012-06-01 05:24

Yes, I'm working on it now.
Seems I broke this with my changes in ocaml 3.08...

(0007491)
garrigue (manager)
2012-06-01 06:49

Fixed in trunk and 4.00, inside transclass.ml, revisions 12531 and 12532

Issue History
Date Modified	Username	Field	Change
2011-06-17 08:32	gio	New Issue
2011-08-03 17:06	doligez	Status	new => acknowledged
2012-05-31 11:26	frisch	Note Added: 0007479
2012-05-31 11:29	frisch	Note Added: 0007480
2012-05-31 18:56	frisch	Note Added: 0007483
2012-06-01 05:13	garrigue	Note Added: 0007485
2012-06-01 05:22	frisch	Note Added: 0007487
2012-06-01 05:23	garrigue	Assigned To	=> garrigue
2012-06-01 05:23	garrigue	Status	acknowledged => assigned
2012-06-01 05:24	garrigue	Note Added: 0007488
2012-06-01 06:49	garrigue	Note Added: 0007491
2012-06-01 06:49	garrigue	Status	assigned => closed
2012-06-01 06:49	garrigue	Resolution	open => fixed
2012-06-01 06:49	garrigue	Fixed in Version	=> 4.00.0+dev

Notes
(0007479) frisch (developer) 2012-05-31 11:26	Even simpler: class a = let _ = new a in object end -> segfault

(0007480) frisch (developer) 2012-05-31 11:29	Note: segfault is at execution time.

(0007483) frisch (developer) 2012-05-31 18:56	Local let-binding in a class declaration are currently executed when the class declaration is evaluated, not when the object is created. I'm tempted to consider it is a design bug that: class c = let () = print_endline "XXX" in object end writes "XXX". With this current semantics, one should indeed restrict references to the class being defined. I.e. in class c = let p = e in .... the class c should not be visible in e. But I'd prefer fixing the semantics of let bindings...

(0007485) garrigue (manager) 2012-06-01 05:13	This evaluation order is intentional. It allows you to define values in an environment where class types are available. Example: class c = let r = ref [] in object (self) method friends = !r initializer r := (self :> c) :: !r end If you put "let r = ref []" this definition goes through, but something strange happens to your types... If you want side-effects at object creation time, then your class should take an argument, or should put them into a field.

(0007487) frisch (developer) 2012-06-01 05:22	> If you want side-effects at object creation time, then your class should take an argument, or should put them into a field. .. or an initializer So, we want the class to be available as a type, but not as a "value", i.e. we should disallow "new c" and "inherit c" in the body of let-binding, right?

(0007488) garrigue (manager) 2012-06-01 05:24	Yes, I'm working on it now. Seems I broke this with my changes in ocaml 3.08...

(0007491) garrigue (manager) 2012-06-01 06:49	Fixed in trunk and 4.00, inside transclass.ml, revisions 12531 and 12532

Relationships