"Goswin von Brederlow" <goswin-...@web.de>: > >>> This is not about optimized compiler in this case but about data >>> representation. Even if you use an optimized compiler (which is not >>> really the case with ocamlopt), you won't change datastructure >>> representation to optimize. >> >> What do you mean? There is no reason in general why a compiler cannot >> optimize data representations, and some do in cases like this. > > How could it? At least for any type that is public in a module. > > The data representation is part of the ABI. As such it is fixed and can > in no way be optimized by the compiler. Only thing you can do is change > the ABI and define a more optimized representation in the first place.
Yes, and I didn't say that OCaml easily could, given external constraints like the one you mention. I only was objecting to the statement that this is not an optimization. > A better representation would be to combine the two: > > bar { > tag = 0 (for Bar) > size = 2 > field[0] = int(x) > field[1] = int(y) > } That is called flattening or unboxing, and in degenerate use cases it can actually be costly because you have to copy the record if you extract it first-class. However, for the original case there would be a much simpler optimization: if a data type has only one constructor (more precisely, one except for nullary ones), you don't need to represent its tag at all, so the whole indirection is unnecessary. /Andreas _______________________________________________ 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