CVS: sml-dist notes,1.1.2.5,1.1.2.6

Update of /cvsroot/smlnj/sml-dist
In directory sc8-pr-cvs8.sourceforge.net:/tmp/cvs-serv26107

Modified Files:
      Tag: primop-branch-2
	notes 
Log Message:
added to notes

Index: notes
===================================================================
RCS file: /cvsroot/smlnj/sml-dist/Attic/notes,v
retrieving revision 1.1.2.5
retrieving revision 1.1.2.6
diff -C2 -d -r1.1.2.5 -r1.1.2.6
*** notes	20 Jun 2006 22:15:23 -0000	1.1.2.5
--- notes	21 Jun 2006 21:14:42 -0000	1.1.2.6
***************
*** 17,21 ****
  instantiation of the typ field of the VALvar, etc. [We could just use
  UNDEFty as the default, unneeded value instead of NONE, but using 
! ty option is cleaner and more explicit about what is going on.
  
  Files affected:
--- 17,21 ----
  instantiation of the typ field of the VALvar, etc. [We could just use
  UNDEFty as the default, unneeded value instead of NONE, but using 
! ty option is cleaner and more explicit about what is going on.]
  
  Files affected:
***************
*** 232,244 ****
  This function is defined in a very obscure way, and returns both the
  instantiated actualTy (actInst) and instantiated specTy (specInst),
! after attempting to unify them.  But first, _some_ of the type variables
! of actInstTvs and specInstTvs are identified by the ListPair.app unifyTy
! line (note that these two lists have different lengths, and it is not clear
! why identifying initial segments of these two lists of type variables makes
! sense.
  
! If the unification is successful, then actInst and specInst are essentially
! the same type.  If the unification fails, then we have two inequivalent, but
! partially unified type expressions.  What is going on here?
  
  
--- 232,245 ----
  This function is defined in a very obscure way, and returns both the
  instantiated actualTy (actInst) and instantiated specTy (specInst),
! after attempting to unify them.  But first, _some_ of the type
! variables of actInstTvs and specInstTvs are identified by the
! ListPair.app unifyTy line (note that these two lists may have
! different lengths, and it is not clear why identifying initial
! segments of these two lists of type variables makes sense.
  
! If the unification is successful, then actInst and specInst are
! essentially the same type.  If the unification fails, then we have two
! inequivalent, but partially unified type expressions.  What is going
! on here?
  
  
***************
*** 362,363 ****
--- 363,404 ----
    on PrimOp related values (former TypeCheckFn) or on PLambdaType stuff
    (InstantiateFn in Elaborate requires parameter InstantiateParam from Semant).
+ 
+ 
+ ======================================================================
+ Example for VARexp typing:
+ 
+ 	val x = Array.length
+ 
+ let
+ 
+    v = the VALvar for Array.length.
+    st = ii2ty v.info = 'a -> int  (the generic primop type)
+    sty = X -> int  (generic instantiation of st, X a fresh type metavariable)
+    insts = [X]
+ 
+    v.typ = 'a array -> int
+    nty = Y array -> int  (generic inst. of v.typ, Y a fresh type metavar)
+ 
+    unify (sty, nty) ==>  X |-> Y array
+  
+    After type generalization of the val binding:
+    boundtvs = [Y]  (in VB)
+    insts = [X]     (in VARexp)
+ 
+ These last don't agree (different metavariables), so in mkVBS in
+ Translate (FLINT/trans/translate.sml), the first VB case will take the
+ else branch and apply mkPE.
+ 
+ It appears that the boundtvs is used in mkPE (Translate) to provide type
+ parameters to primop invocations.  [Why boundtvs and not insts?]
+ 
+ 
+ ======================================================================
+ 
+ Zhong questions:
+ 
+ 1. What is the relevance of the comment in system/smlnj/init/dummy.sml to the
+ code in that file?
+ 
+ 2. What is the meaning of the comment after the PrimTypes (re)declaration at
+ the top of system/smlnj/init/built-in.sml?
\ No newline at end of file


All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642