[MLton-devel] types for RSSA

[Matthew Fluet]

> In IntOrPointer, if the objects vector is empty, it is just an enum,
> with variants 0, 1, ..., enumSize - 1.  If the enumSize is 0 the
> objects vector has one element, then we have a tuple.  Otherwise, we
> have a sum type where the variants can be distinguished by the object
> type index, since it is disallowed for the same index to appear
> twice.

I'm a little confused on how datatypes with both value carrying and
non-value carrying variants are represented.  I.e., is there a case when
enumSize < Vector.length objects?

So, SSA datatypes like

list_4 = nil_3 | ::_4 of (list_4, char)
list_3 = nil_4 | ::_3 of (list_3, char vector)
list_2 = nil_2 | ::_0 of (list_2, (int * int))
bufStyle_0 = Line_0 of (word8 array) | Buffered_0 of (word8 array)
bool = false | true

would be represented as:

(* nil_3 represented as 1
 * ::_4 represnted as index 0
 *)
list_4 =
Mtype.IntOrPointer {enumSize = 2,
                    objects = #[{index = 0}]}
(* nil_4 represented as 1
 * ::_3 represnted as index 1
 *)
list_3 =
Mtype.IntOrPointer {enumSize = 2,
                    objects = #[{index = 1}]}
(* nil_2 represented as 1
 * ::_0 represnted as index 2
 *)
list_2 =
Mtype.IntOrPointer {enumSize = 2,
                    objects = #[{index = 2}]}
(* Line_0 represented as index 3
 * Buffered_0 represented as index 4
 *)
bufStyle_0 =
Mtype.IntOrPointer {enumSize = 2,
                    objects = #[{index = 3}, {index = 4}]}
(* false represented as 0
 * true represented as 1
 *)
bool =
Mtype.IntOrPointer {enumSize = 2,
                    objects = #[]}

charvector =
Mtype.IntOrPointer {enumSize = 0,
                    objects = #[{index 5}]}
intXint =
Mtype.IntOrPointer {enumSize = 0,
                    objects = #[{index = 6}]}
word8array =
Mtype.IntOrPointer {enumSize = 0,
                    objects = #[{index = 7}]}

objectTypes =
#[ObjectType.Tuple
  (MemChunk.T
   {components = #[{mutable = false,
                    offset = 0,
                    ty = list_4},
                   {mutable = false,
                    offset = 4,
                    ty = Mtype.Char}],
    width = 5}),
  ObjectType.Tuple
  (MemChunk.T
   {components = #[{mutable = false,
                    offset = 0,
                    ty = list_3},
                   {mutable = false,
                    offset = 4,
                    ty = charvector}],
    width = 8}),
  ObjectType.Tuple
  (MemChunk.T
   {components = #[{mutable = false,
                    offset = 0,
                    ty = list_3},
                   {mutable = false,
                    offset = 4,
                    ty = intXint}],
    width = 8}),
  ObjectType.Tuple
  (MemChunk.T
   {components = #[{mutable = false,
                    offset = 0,
                    ty = word8array}],
    width = 4}),
  ObjectType.Tuple
  (MemChunk.T
   {components = #[{mutable = false,
                    offset = 0,
                    ty = word8array}],
    width = 4}),
  ObjectType.Vector
  (MemChunk.T
   {components = #[{mutable = false,
                    offset = 0,
                    ty = Mtype.Char}],
    width = 1}),
  ObjectType.Tuple
  (MemChunk.T
   {components = #[{mutable = false,
                    offset = 0,
                    ty = Mtype.Int},
                   {mutable = false,
                    offset = 0,
                    ty = Mtype.Int}],
    width = 8}),
  ObjectType.Vector
  (MemChunk.T
   {components = #[{mutable = false,
                    offset = 0,
                    ty = Mtype.Word8}],
    width = 1})]


How about these:
list_1 = nil_1 | ::_2 of (list_1, (bufStyle_0 * bool ref) ref)
list_0 = nil_0 | ::_1 of (list_0, list_1 ref)
exn = ex_undefined_0
    | ClosedStream_0
    | Subscript_0
    | Size_0
    | Overflow
    | Io_0 of (char vector, exn)
    | SysErr_0 of (char vector)
    | Fail_0 of (char vector)

> 2. Using the object type index is the variant tag.  This supports the
> strategy of using consecutive object types for all the variants to
> make dispatch fast,

Oh, do you mean that both the nil and the :: variants would be represented
by type indices?  That would seem to cost a little more space than the
current system.

> 3. ... 7.

All those points seem good.

> 8. Generation of more type-correct C, by usin a C structs for each
> MemChunk and C union for IntOrPointer.  Perhaps this would give C some
> aliasing info?

That's an interesting idea.  I don't know enough about C aliasing rules to
know if it's really feasible.



-------------------------------------------------------
This sf.net email is sponsored by: To learn the basics of securing 
your web site with SSL, click here to get a FREE TRIAL of a Thawte 
Server Certificate: http://www.gothawte.com/rd524.html
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel