[bitc-dev] Polyinstantiating local definitions -- take 2.5
Swaroop Sridhar
swaroop at cs.jhu.edu
Fri Jul 28 02:02:16 EDT 2006
The take 2 algorithm almost seems to work, there is another case we should
be careful. The above cases involved uses of specialization of a
polymorphic definition, and not the defined identifier as is. However, if
we have:
(define top (begin nil ()))
Here, the type of nil is not fully specified. So, it could be any (one)
thing. We could preserve the original definition of list and this nil as
is, but that will require us to deal with type variables in the later
stages (ex: Closure conversion/ closure environments)
So, probably one -- not very pretty? -- solution is to consider
instantiating the unspecified type variable to ty_ugly. ty_ugly behaves
exactly like unit, but when we display types at top level, we will
display it like a type variable for the user. Now, nil will have type
(list ugly) and we have no problem.
For example:
(define top
(let ((mynil nil))
mynil:(list bool)
mynil:(list int32)
mynil))
will turn into:
(define top
(let ((mynil#UR_list_bool nil#UR_list_bool)
(mynil#UR_list_int32 nil#UR_list_int32)
(mynil#UR_list_ugly nil#UR_list_ugly))
mynil#UR_list_bool
mynil#UR_list_int32
mynil#UR_list_ugly))
If we start from things that are concrete and always specialize to fully
concrete definitions, I think this will work out OK.
Swaroop.
More information about the bitc-dev
mailing list