0003978: Optimization of types

Notes
(0003598) xleroy (administrator) 2006-03-24 10:00	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" abstract.

(0003599) Christophe (reporter) 2006-03-24 12:22	type color = Color of int let dark = function Color i -> Color (i+1) but... module Color : sig type color 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.

(0003600) n8gray (reporter) 2006-03-25 01:53 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)

Issue History
Date Modified	Username	Field	Change
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

Relationships