[bitc-dev] Addition of DEFREPR

[Swaroop Sridhar]

Jonathan S. Shapiro wrote:
> I would like your opinion on whether this can be made to work, and how
> much effort it would take. I'm sure it will change before we implement
> it, so I wouldn't go rushing ahead. I'm particularly interested in two
> parts:
> 
>   How much of a pain in the ass are the constructors going to be
>   from the compiler perspective?

In all passes other than the code generator, the defrepr is can be 
treated as the following transformation:

(defrepr dr
   ((tag swizzled unswizzled)
    (tag left right)
    (case (swizzled (i:int32 j:int32))
          (unswizzled (b:bool)))
    (invariant d:double)
    (case ((swizzled left) (k:int32)))))

    ||
     V

(defunion dr
    (dr-swizzled-right i:int32 j:int32 d:double)
    (dr-swizzled-left  i:int32 j:int32 d:double k:int32)
    (dr-unswizzled-right b:bool d:double)
    (dr-unswizzled-left  b:bool d:double))

The constructor applications will also work naturally:

(dr swizzled right 5 6 2.0 7)

||
V

(dr-swizzled-right 5 6 2.0 7)

So, *probably* the right thing to do is to transform -- a copy of -- 
defreprs into defunions (or defstructs if there are only invariants) and 
let the compiler alone. Only the code generator will have to emit the 
structure/union and constructors correctly. This may seem like an 
explosion of constructors, but it will hopefully be contained in practice.

>   How much of a pain in the ass are the anonymous stucture types (see
>   reprcase) going to be?

By anonymous I think you mean a gen-sym structure. In BitC all 
structures must have a name because structure types are unified based on 
their names. In order to achieve this, probably the right thing to do is 
to change the above transformation as:

(defunion dr
    (dr-swizzled-right (__dr-swizzled-right i:int32 j:int32 d:double))
    (dr-swizzled-left  (__dr-swizzled-left i:int32 j:int32 d:double
                                k:int32))
    (dr-unswizzled-right (__dr-unswizzled-right b:bool d:double))
    (dr-unswizzled-left  (__dr-unswizzled-left  b:bool d:double)))

where each of the __dr... forms are structures whose definitions the 
compiler will add prior to the defrepr.

So,
(reprcase e ((id swizzled right  id.d))
              (otherwise 0.0))

||
V

(reprcase e ((id:__dr-swizzled-right swizzled right  id.d))
              (otherwise 0.0))

As you have noted in the spec, we may do this for all unions as well.

> also, your opinion on what scope the case-id tags should have would be
> appreciated.
In the above scheme, the case tags are scoped within the defrepr, 
because they are always mentioned along with the defrepr's name. So, it 
is as if we wrote these tags as dr-swizzled-right, etc, which are 
guaranteed to be unique at top level. Right?


> This is good
> enough to capture Coyotos capabilities, which is the main problem that I
> was trying to solve. I haven't get looked at whether it is enough to
> handle GDT entries.

Is the rule:
> A case form may make reference to any tagid that is mentioned in any 
> lexically preceding tag form within the same defrepr

necessary? Conceptually, the compiler can process all tag forms first, 
so that all legs can make use all tags. I think, in the case of GDT 
entries, some fields come before the tag.

The specification does not say that the tag field must be placed at the 
location where it is declared, although I think this is the intention.

We may have to include a tag-type for each tag declaration. Also, the 
bits of a single tag may be broken into two parts and stored at 
different locations within the structure (gate descriptor?) we may have 
to make provisions for this also.

--

In the definition of defrepr body,

> (tag tagid1 ... tagidn)
> nm[:ty]
> (case (tagid (body))
>       ...
>       ((tagid1 ... tagidj) (body))
>       ...
>       (tagid (body))

Is the nm supposed to be an invariant field name? If so, I guess it 
should be written as:

(invariant nm:type)

where the type is not optional.

Swaroop.