|Anonymous | Login | Signup for a new account||2017-10-19 07:31 CEST|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0003978||OCaml||~DO NOT USE (was: OCaml general)||public||2006-02-18 15:45||2016-12-06 22:26|
|Target Version||Fixed in Version|
|Summary||0003978: Optimization of types|
|Description||When I defined a mono type like|
type color = Color of int ;;
all values of type color are integers. But it seems that, even if I compile with ocamlopt, such value are represented within a block. It seems completly useless to do such a representation as there is only one constructor in the color type, as core values are integers, and as typage is a static operation....
So is it a complex optimization, or is there some difficulty that I do not see that prevent such an optimization ?
Thank you !
|Tags||No tags attached.|
This representation optimization has been considered before. Unclear to me
that a special case is warranted. Similar efficiency can be achieved
by "type color = int", possibly with a signature constraint to make "color"
type color = Color of int
let dark = function Color i -> Color (i+1)
module Color : sig
val of_int : int -> color
val to_int : color -> int
end = struct
type color = int
let of_int x = x
let to_int x = x end
let dark c = Color.of_int (Color.to_int c + 1)
this is a more complex code just for efficiency ! This makes difficult to use primitive types without merging them (just say type color = int).
This is specially true when I want several different ints or strings or something primitive... The use of a constructor as a flag is very useful in those cases.
edited on: 2007-01-05 23:59
I think Christophe makes the case for this pretty well, but I just wanted to add my support. I keep wanting to use this sort of construct for units:
type cm = Cm of float
type inch = Inch of float
let in_of_cm (Cm f) = Inch (0.393700787 *. f)
let cm_of_in (Inch f) = Cm (2.54 *. f)
I would argue that guaranteeing an efficient representation for this would lead to more reliable software, since programmers wouldn't have to worry about killing performance with needless boxing ops, even in low-level math code.
Update: Fixed my math! (blush)
|Fixed by https://github.com/ocaml/ocaml/pull/606 [^]|
|2006-02-18 15:45||Christophe||New Issue|
|2006-03-24 10:00||xleroy||Note Added: 0003598|
|2006-03-24 10:00||xleroy||Priority||normal => low|
|2006-03-24 10:00||xleroy||Status||new => acknowledged|
|2006-03-24 10:00||xleroy||Resolution||open => suspended|
|2006-03-24 12:22||Christophe||Note Added: 0003599|
|2006-03-25 01:53||n8gray||Note Added: 0003600|
|2007-01-05 23:59||n8gray||Note Edited: 0003600|
|2016-12-06 22:26||shinwell||Note Added: 0016672|
|2016-12-06 22:26||shinwell||Status||acknowledged => resolved|
|2016-12-06 22:26||shinwell||Resolution||suspended => fixed|
|2016-12-06 22:26||shinwell||Assigned To||=> shinwell|
|2017-02-23 16:36||doligez||Category||OCaml general => -OCaml general|
|2017-03-03 17:55||doligez||Category||-OCaml general => -(deprecated) general|
|2017-03-03 18:01||doligez||Category||-(deprecated) general => ~deprecated (was: OCaml general)|
|2017-03-06 17:04||doligez||Category||~deprecated (was: OCaml general) => ~DO NOT USE (was: OCaml general)|
|Copyright © 2000 - 2011 MantisBT Group|