[Caml-list] Re: value restriction
on another note (but staying very much on the same topic), why won't the following generalize: # let foo = let counter = ref 0 in let bar = !counter in let baz = fun x - bar in baz val foo : '_a - int = fun baz clearly has a polymorphic type, yet foo doesn't. Is there any way around this ? --Jacques L. On Fri, Jan 1, 2010 at 6:05 PM, Jacques Le Normand rathere...@gmail.comwrote: Hello caml-list, with respect to the value restriction, what exactly constitutes a value? the textbook definition doesn't seem to hold, since the following generalizes: let f = let x = 1 in fun g h x - g (h x);; while this won't: let f () = let x = (fun x - x) (fun x - x) in fun g h x - g (h x);; cheers --Jacques L. ___ 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
Re: [Caml-list] Re: value restriction
on another note (but staying very much on the same topic), why won't the following generalize: # let foo = let counter = ref 0 in let bar = !counter in let baz = fun x - bar in baz val foo : '_a - int = fun It's even worse: Objective Caml version 3.11.1 # let _ = ref () in fun x - x ;; - : '_a - '_a = fun I am sure this makes sense in France. Happy new year! Andrej ___ 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
Re: [Caml-list] Re: value restriction
On Sat, Jan 2, 2010 at 5:46 PM, Andrej Bauer andrej.ba...@andrej.com wrote: on another note (but staying very much on the same topic), why won't the following generalize: # let foo = let counter = ref 0 in let bar = !counter in let baz = fun x - bar in baz val foo : '_a - int = fun It's even worse: Objective Caml version 3.11.1 # let _ = ref () in fun x - x ;; - : '_a - '_a = fun I am sure this makes sense in France. Happy new year! Andrej The idea is to prevent potentially wrong programs. It is bad to write (let x = ref [ ] in x := [hello] ; x := [2]). So the algorithm — that prevents the generalization process of expressions such as (ref [ ]) — prevents the generalization of all application expressions. (actually, almost all because I think there are a few exceptions such as # let f = let x = ref [] in !x ;; val f : 'a list = []). Making a perfect algorithm that generalizes only and always when permitted is very hard (maybe it's impossible because not decidable?). This example shows a program that is rejected because its type is not computable in Caml's type system : (fun x - x x) (fun x - x) (fun x - x) It could be a valid program (i.e. it wouldn't lead to a type crash at runtime), but it is rejected because the type system is not capable of asserting its correctness. (I am not certain I am not off topic) Cheers, -- Philippe Wang m...@philippewang.info ___ 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
[Caml-list] Prevalence of duplicate references in the heap
I took an odd design decision with HLVM and made references a struct of run-time type, metadata (e.g. array length), pointer to mark state and pointer to data. So every reference consumes 4x32=128 bits rather than the usual 32 bits but heap-allocated values no longer require a header. My performance results really surprised me. For example, the gc benchmark in the HLVM test suite fills a hash table that is represented by an array spine containing references to array buckets. Despite having (fat) references everywhere, HLVM is 2.2x faster than OCaml on x86. The main disadvantage of HLVM's approach is probably that every duplicate reference now duplicates the header information, wasting 96 bits. However, I do not believe references are duplicated in the heap very often. Both trees and hash tables contain many references but none are duplicated. So I'm wondering if anyone has studied the makeup of heaps in idiomatic OCaml code and could point me to data on the proportion of the heap typically consumed by duplicate references, i.e. how much space is HLVM likely to waste? Many thanks, -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?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
Re: [Caml-list] Re: value restriction
On Sat, Jan 2, 2010 at 5:46 PM, Andrej Bauer andrej.ba...@andrej.com wrote: It's even worse: Objective Caml version 3.11.1 # let _ = ref () in fun x - x ;; - : '_a - '_a = fun I am sure this makes sense in France. I'm not sure why you're singling out France. % sml Standard ML of New Jersey v110.69 [built: Sun Jun 7 19:18:24 2009] - let val _ = ref () in fn x = x end ; stdIn:1.1-1.36 Warning: type vars not generalized because of value restriction are instantiated to dummy types (X1,X2,...) val it = fn : ?.X1 - ?.X1 This shouldn't be surprising: a let form is expansive and therefore cannot have a polymorphic type. OCaml is much more liberal than SML about what forms it considers non-expansive [1]. -- Kaustuv [1] http://caml.inria.fr/pub/papers/garrigue-value_restriction-fiwflp04.pdf ___ 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
