CVS: sml-dist notes,1.1.2.12,1.1.2.13

David MacQueen <[email protected]> Thu, 27 Jul 2006 13:56:00 -0700
Newsgroups gmane.comp.lang.sml.smlnj.commits
Message-ID <[email protected]>
Update of /cvsroot/smlnj/sml-dist
In directory sc8-pr-cvs8.sourceforge.net:/tmp/cvs-serv7975

Modified Files:
      Tag: primop-branch-2
	notes 
Log Message:
added program desciption, a couple of questions

Index: notes
===================================================================
RCS file: /cvsroot/smlnj/sml-dist/Attic/notes,v
retrieving revision 1.1.2.12
retrieving revision 1.1.2.13
diff -C2 -d -r1.1.2.12 -r1.1.2.13
*** notes	25 Jul 2006 17:02:19 -0000	1.1.2.12
--- notes	27 Jul 2006 20:55:58 -0000	1.1.2.13
***************
*** 1,2 ****
--- 1,47 ----
+ Primop2 Notes
+ 
+ Primop2 Branch Info
+ ===================
+ 
+ The development branch name is:
+ 
+   primop-branch-2
+ 
+ The tag for the root of primop-branch-2 is:
+ 
+   dbm-20060615-base-primop-branch-2
+ 
+ 
+ ======================================================================
+ The Program
+ 
+ Our goal is to clean-up and simplify the code of the SML/NJ Front End
+ (everything before the translate phase), and as far as possible turn it
+ into a self-contained SML front end "library" that could be used outside
+ the SML/NJ compiler. There are several related subgoals:
+ 
+ 1. A major part of this effort aims to remove dependencies on FLINT
+ constructs and interfaces from the front end. This requires that we
+ understand what the FLINT-related values and computations are used for
+ so that we can reproduce that functionality in the translate phase,
+ ultimately producing the same FLINT intermediate language.
+ 
+ 2. We want to avoid transformations of the abstract syntax before type
+ checking, since these transformations reduce the faithfulness of the
+ abstract syntax to the original source and lead to less useful and less
+ accurate type error messages. Abstract syntax transformations/normalizations
+ that have presumably been introduced to be helpful for FLINT should be
+ be moved into the translate phase.  All we need to do is make sure
+ that the abstract syntax captures and retains all static information that
+ the translate phase will need to produce the correct plambda code.
+ 
+ 3. We want to simplify the FLINT code (and ultimately the object code)
+ by eliminating the real array => realarray representation
+ optimization.  We need to understand what parts of the translation is
+ specifically supporting this optimization, so that those parts can be
+ simplified.
+ 
+ 
+ ======================================================================
  Questions:
  
***************
*** 82,87 ****
  strrec of the root structure. 
   
  ======================================================================
! Old Primop Notes (from old primop branch)
  
  These notes are my attempt to figure out what appears to be a very kludgy
--- 127,133 ----
  strrec of the root structure. 
   
+ 
  ======================================================================
! Old Primop Notes (from old primop branch, mostly obsolete)
  
  These notes are my attempt to figure out what appears to be a very kludgy
***************
*** 377,380 ****
--- 423,427 ----
  
  ======================================================================
+ 
  Example for VARexp typing:
  
***************
*** 407,417 ****
  ======================================================================
  
! 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?
  
  3. The Single Generalization Conjecture (SGC): Each type metavariable
--- 454,475 ----
  ======================================================================
  
! [FLINT] Questions:
  
! The primop-branch-2 code contains a number of questions in comments
! marked by the string "[KM ???]".  You can find them by grepping the
! source for that string.
! 
! The following questions are in more or less random order, added as
! they came up in our reading of the code.  Most but not all relate to
! the interaction of FLINT and the front end, or to FLINT internals.
! 
! 
! 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?
  
  
  3. The Single Generalization Conjecture (SGC): Each type metavariable
***************
*** 458,461 ****
--- 516,520 ----
  indicating two independent generalizations.
  
+ 
  5. Two lexp types in FLINT
  There are two types named lexp: PLambda.lexp (in FLINT/plambda/plambda.sml)
***************
*** 463,473 ****
--- 522,535 ----
  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.
  
***************
*** 477,479 ****
  
  generates a surprising complex abstract syntax representation, looking
! something like ...
--- 539,576 ----
  
  generates a surprising complex abstract syntax representation, looking
! something like (using some shorthand notations) ...
! 
!    STRB{name = "X",
! 	str = bindStr,
! 	def = LETstr (
! 		STRdec [
! 		  STRB{name = "<tempStr>",
! 		       str = resStr
! 		       def = LETstr (
! 			       VB{pat = vv_x, exp = VARexp(vv_len)), ...}
! 			       STRstr([VALbind(vv_x)])}],
! 		VARstr(resStr)
! 	      )
!        }
! 
! where resStr is the structure record returned for the rhs strexp by
! elabStr, and bindStr is the same as resStr except the dacc field is
! replaced by a new lvar, vv_x is the VALvar for the bound variable x,
! and vv_len is the VALvar for Array.length.
! 
! This strips down to a skeleton like:
! 
!     let lv_b =             (* lv_b = lvar for bindStr *)
!         let lv_r = ...     (* lv_r = lvar for resStr *)
!          in let <component var decls>
! 	     in [component vars]
!         in lv_r
! 
! What is the purpose of the outer layer of let binding, and the shift
! in lvars from lv_r to lv_b?
! 
! 
! 9. In Absyn, why do CONexp's also have a tyvar list parameter (like VARexp?).
! Is this only relevant to a few special constructors (maybe ref?), or is it
! also used for ordinary user defined constructors?  Similarly for CONpat.
! 


-------------------------------------------------------------------------
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