CVS: sml-dist notes,1.1.2.11,1.1.2.12

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

Modified Files:
      Tag: primop-branch-2
	notes 
Log Message:
added questions to notes, touched up sigmatch

Index: notes
===================================================================
RCS file: /cvsroot/smlnj/sml-dist/Attic/notes,v
retrieving revision 1.1.2.11
retrieving revision 1.1.2.12
diff -C2 -d -r1.1.2.11 -r1.1.2.12
*** notes	24 Jul 2006 22:43:35 -0000	1.1.2.11
--- notes	25 Jul 2006 17:02:19 -0000	1.1.2.12
***************
*** 191,207 ****
  to type ty.
  
! If unifyTyvars had a left-to-right instantiation bias instead of a right-to-left
! bias, the unification would instantiate all the tyvars in actInstTvs and none of the
! tyvars in specInstTvs, so the resultant type actInst will be equivalent to specInst
! -- note that in this special case unification will not have to adjust any type
! variable attributes, since all depths will be infinity and the consistency of
! equality properties will already have been guaranteed by the previous call of
! TU.compareTypes in matchTypes.
  
! In this case, eqvTnspTy could just return specInst and specInstTvs without bothering
! to perform the useless unification.  It is not clear why this would not suffice anyway,
! i.e. eqvTnspTy could simply be replaced by TU.instantiatePoly applied to specty,
! with tyvarType then mapped over the resulting specInstTvs. The simplified
! version of eqvTnspTy would be
  
      fun eqvTnspTy (specty: ty) : (ty * tyvar list) = 
--- 191,209 ----
  to type ty.
  
! If unifyTyvars had a left-to-right instantiation bias instead of a
! right-to-left bias, the unification would instantiate all the tyvars
! in actInstTvs and none of the tyvars in specInstTvs, so the resultant
! type actInst will be equivalent to specInst -- note that in this
! special case unification will not have to adjust any type variable
! attributes, since all depths will be infinity and the consistency of
! equality properties will already have been guaranteed by the previous
! call of TU.compareTypes in matchTypes.
  
! In this case, eqvTnspTy could just return specInst and specInstTvs
! without bothering to perform the useless unification.  It is not clear
! why this would not suffice anyway, i.e. eqvTnspTy could simply be
! replaced by TU.instantiatePoly applied to specty, with tyvarType then
! mapped over the resulting specInstTvs. The simplified version of
! eqvTnspTy would be
  
      fun eqvTnspTy (specty: ty) : (ty * tyvar list) = 
***************
*** 413,424 ****
  the top of system/smlnj/init/built-in.sml?
  
! 3. The Single Generalization Conjecture: Each type metavariable that
! is not instantiated is generalized at a single variable binding. 
  Consequence: the metavariable can be updated with a deBruijn index for
! the corresponding generalized polymorphic variable.  [The code for mkPE
! in translate.sml seems to imply this is not the case.]
  
  
! More on Single Generalization Conjecture
  
  Here is an expression containing two mutually recursive functions that
--- 415,434 ----
  the top of system/smlnj/init/built-in.sml?
  
! 3. The Single Generalization Conjecture (SGC): Each type metavariable
! that is not instantiated is generalized at a single variable binding.
  Consequence: the metavariable can be updated with a deBruijn index for
! the corresponding generalized polymorphic variable.  [The code for
! mkPE in translate.sml seems to imply this is not the case.]
  
+ If the SGC is true, then the "restore" function in Translate.mkPE is
+ unnecessary, as the metavariables in question will only be used once.
  
! The SGC has been tested experimentally by removing the call of restore
! in mkPE, and bootstrapping the compiler.  The runtime check in mkPE 
! that tests for previously used generalized metavariables was not
! triggered.
! 
! 
! 4. More on Single Generalization Conjecture
  
  Here is an expression containing two mutually recursive functions that
***************
*** 448,453 ****
  indicating two independent generalizations.
  
! 4. Two lexp types in FLINT
  There are two types named lexp: PLambda.lexp (in FLINT/plambda/plambda.sml)
  and FLINT.lexp (in FLINT/flint/flint.sml).  The two lexp's have quite different
  definitions. What are the roles of these two lexp types?
--- 458,479 ----
  indicating two independent generalizations.
  
! 5. Two lexp types in FLINT
  There are two types named lexp: PLambda.lexp (in FLINT/plambda/plambda.sml)
  and FLINT.lexp (in FLINT/flint/flint.sml).  The two lexp's have quite different
  definitions. What are the roles of these two lexp types?
+ 
+ 6. mkAccInfo in Translate (FLINT/trans/translate.sml) ignores the
+ second argument (formerly info, now prim).  Why is this?  Doesn't this
+ mean that primops get lost?
+ 
+ 7. What is the point of PACKexp?  In mkExp in Translate (FLINT/trans/translate.sml)
+ it is just stripped off.
+ 
+ 8. Complex abstract syntax for a simple structure declaration.
+ 
+ A simple declaration like
+ 
+    structure X = struct val x = Array.length end
+ 
+ generates a surprising complex abstract syntax representation, looking
+ something like ...


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV