[Grace-core] [] for types' type parameters (with possible application to classes)

Michael Homer mwh at ecs.vuw.ac.nz
Thu Nov 13 19:45:34 PST 2014


> From: Kim Bruce <kim at cs.pomona.edu>
> To: Michael Homer <Michael.Homer at ecs.vuw.ac.nz>
> Cc: "grace-core at cecs.pdx.edu" <grace-core at cecs.pdx.edu>
> Date: Thu, 13 Nov 2014 18:10:56 -0800
> Subject: Re: [Grace-core] [] for types' type parameters (with possible application to classes)
>
> A very quick reaction.
>
> 1) This is not a minor proposal -- at least not the latter parts.  Making types first class has lots of consequences that can be quite difficult to predict up front.
> <...>
> Having a parallel system of reified types that "represent" types, but are not types, can be safer and might be worth exploring, especially in association with "match".
We already have this latter. Essentially that is what I meant by
having types be first class - I'm talking about dynamic runtime
behaviour of the reified type objects only, and having type names
always be references to those objects rather than being methods.

The only change visible in respect to static typing is syntactic,
introducing a distinction between type parameters on methods and on
other types. A checking dialect is free to analyse, ignore, or reject
programs that use more dynamic parameterisation or aliasing.
> 2) A minor question (that may be connected to larger ones) is what is the type of a type definition?  If you write
>    def ListOfStrings = List[String]
> then if you are in a statically typed dialect, what is the type of ListOfStrings, and
>    def MyList = List
> is even worse.
The type of ListOfStrings is Pattern[List[String]], or more probably
Type[List[String]] <: Pattern[List[String]] (Type including the [] and
+ operators). This is already the case.
-Michael


More information about the Grace-core mailing list