[bitc-dev] Input mechanism for dummy types?
swaroop at cs.jhu.edu
Tue Aug 22 09:31:16 CDT 2006
Jonathan S. Shapiro wrote:
> 4. Finally, a question: should we think of these as dummy types, or
> as explicitly unresolvable type variables?
> [I am hoping that the answer is "variables"]
> Assuming that these are dummy type variables, then perhaps one of the
> Where '# indicates a dummy type variable, or
> (forall (Dummy 'a) (fn (('a)) 'a))
> Is one of these sensible, or am I mixing up variables and types?
The dummy types are not variables, in the same sense that the type unit,
int32 or bool is not variable. They are certainly not universally
qualified as in
(forall (Dummy 'a) (fn (('a)) 'a))
because the reason we generate dummy variables is:
i) There was a type variable that could not be universally quantified.
ii) We did not even want to leave the variable monomorphic, and wanted
to fix it to an un-morphable concrete type.
I instantiated them to dummy types only because SML does so. We can also
instantiate all top-level monomorphic variables unit, if it is so desired.
> 2. The concrete syntax beginning with # is probably not a good idea,
> because this space is reserved.
I agree. # is used by the compiler as of now for mangling and we should
continue to keep it reserved.
If we don't want non-variables to start with a ', we can write them as
!x, !y, etc, but this may be confusing for people who come from the ML
More information about the bitc-dev