SCM Repository
[smlnj] / sml / branches / primop-branch-3 / compiler / DEVNOTES / ElabMod / primary-types |
View of /sml/branches/primop-branch-3/compiler/DEVNOTES/ElabMod/primary-types
Parent Directory | Revision Log
Revision 3331 -
(download)
(annotate)
Tue May 12 16:06:26 2009 UTC (11 years, 6 months ago) by dbm
File size: 4559 byte(s)
Tue May 12 16:06:26 2009 UTC (11 years, 6 months ago) by dbm
File size: 4559 byte(s)
added some questions
Primary & Secondary types --------------------- Concerning the translation of signatures (functor parameter signatures in particular) into kinded type variable abstractions. A functor parameter signature will be translated into a type abstraction (TFUN) over several type variables. These type variables correspond to certain tycon and functor elements of the signature, and the list is flattened over the signature hierarchy. Any nondefined functor element gets a type variable, whose kind is derived from the functor signature of that element. A tycon element is "primary", and gets a type variable, if it is _formal_, i.e. neither defined, nor a datatype. Datatypes are viewed has having a defined structure given by the datatype spec. The kind of the plambda type variable for a primary tycon is computed from the arity of the tycon (PLambdaType.tkc_int). A formal tycon is a GENtyc with kind=FORMAL. Only one type variable is included per sharing equivalence class of tycons (& functors?). Hence instantiation (which determines the sharing equivalence classes and their representative elements) is naturally involved in the determination of the primary tycons and their plambda type variables. It is therefore not possible (not easy?) to compute the primary tycons from a signature without performing instantiation or an analysis of sharing equivalence that would be closely related to instantiation. How could the primary tycons of a signature be identified. (a) a symbolic path (b) an entity path (c) a flexible stamp (associated with the representative tycon in an instantiation) (a) and (b) are intertranslatable from the signature representation. I.e. given a symbolic path for an element, we follow that path, extracting the entityVar for each spec along the way to form the corresponding entity path. Starting with the entity path, we can search for the corresponding element in successive elements lists and capture the corresponding symbolic names to form a symbolic path. Representing a primary tycon as a flexible stamp, as in (c), is clearly relative to a particular instantiation of the signature. Unfortunately, because elaboration introduces tycons directly into the abstract syntax of the functor body, particularly GENtycs which can only be distinguished by their stamps, neither symbolic paths nor entity paths are adequate to identify primary types throughout the abstract syntax. ----------------------- Translating tycons. Primary tycons need to be translated to the corresponding plambda type variable in the TransTypes (in toTyc). Currently tycpaths (FLINT/trans/tycpath.sml) are used as an intermediate form in the translation from (frontend) types to plambda types. It is likely that this intermediate representation can be eliminated. The tycpath for a tycon is either just the tycon itself (TP_TYC tyc), or a representation of a plambda type variable, TP_VAR{tdepth,num,kind}. Compound tycpaths (TP_FCT, TP_APP, and TP_SEL) have to do with functors and structures. [Q: What is the role of TP_TYC? Shouldn't all primary tycons be represented by a TP_VAR? If so, are the arguments of TP_TYC secondary tycons? In that case, what do they have to do with the plambda type or kind?] --------------------- Determining the tkind (plambda kind) of a functor element. A functor element in a signature is translated into a type function and also into a lambda term. The type function has a kind (tkind), which must be computable from the functor signature. PLambda kinds have the following forms: fun K ... K -> K -- an n-ary type operator seq K ... K -- an n-tuple of type constructors 0 ... n -- a basic tycon of arity k ---------------------- External functors and primary types in closures Because pidinfo in persistent maps contain lty information for the given pid, the lty for externally referenced functor (i.e., an occurrence of a functor name that is defined outside the compilation unit), the FLINT lty must be computed. The lty does not have to be computed before elaboration of the functor variable for local functor variables because we do not create persistent map entries for those. [Q: What is a pidinfo, and where is it defined?] [Q: Where in the code is the lty for an external functor computed?] We translate externally defined functor variables by looking up the path until we get to an EXTERN access. Then we compute the lty for that functor variable given that functor and compInfo. [Q: How? What does compinfo have to do with this?]
root@smlnj-gforge.cs.uchicago.edu | ViewVC Help |
Powered by ViewVC 1.0.0 |