CVS: sml-dist notes,1.1.2.1,1.1.2.2

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

Modified Files:
      Tag: primop-branch-2
	notes 
Log Message:
added more questions and suggestions

Index: notes
===================================================================
RCS file: /cvsroot/smlnj/sml-dist/Attic/notes,v
retrieving revision 1.1.2.1
retrieving revision 1.1.2.2
diff -C2 -d -r1.1.2.1 -r1.1.2.2
*** notes	15 Jun 2006 22:28:07 -0000	1.1.2.1
--- notes	19 Jun 2006 16:28:33 -0000	1.1.2.2
***************
*** 12,19 ****
  constructors of exp in ElabData/syntax/absyn.s??
  Should be able to replace list of metavariables by (instantiated)
! variable type.
  Files affected:
!  ElabData/syntax/absyn.s??  [done]
!  Elaborator/types/typecheck.sml [done]
   Elaborator/modules/sigmatch.sml [?]
   FLINT/trans/translate.sml [?]
--- 12,25 ----
  constructors of exp in ElabData/syntax/absyn.s??
  Should be able to replace list of metavariables by (instantiated)
! variable type. Or, since in most cases this is not relevant (it's
! represented by [] currently), it should be a type option.  This type
! would the the instantiated "variable type", i.e. based on a generic
! 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:
!  ElabData/syntax/absyn.s??  [done - except for option]
!  Elaborator/types/typecheck.sml [done - except for option]
   Elaborator/modules/sigmatch.sml [?]
   FLINT/trans/translate.sml [?]
***************
*** 22,25 ****
  
  4. Why do CONpats (see CONpat case of patType in typecheck.sml) need
! the "insts" value?  What do they have to do with primops?
  
--- 28,49 ----
  
  4. Why do CONpats (see CONpat case of patType in typecheck.sml) need
! the "insts" value?  What do they have to do with primops? Where is this
! information used?
! 
! 5. Catalogue of primops:
! We need a complete catalog of all primops, with their initial types (primop
! generic type), and the modules and types where they are ultimately defined
! in the Basis modules.
  
+ 6. Numbered primops:
+ Perhaps in the front end, primops can be respresented by a simple number
+ (defined in the basic primop module). The mapping between primop numbers
+ and their generic types could be implemented as a table or finite map.
+ Generic primops that are used at different types could be split into a set
+ of primop numbers, one for each final (variable) type. FLINT would be 
+ responsible for recognizing that several primop numbers represent the same
+ generic underlying primop.  Then the primop numbers could be mapped to their
+ exact (variable) type in the InLine module. One problem here is that some
+ type constructors appearing in variable types are not defined (yet) in
+ the PrimTypes module -- presumably we could fix this by adding them as
+ additional primite types. Examples are probably array and vector tycons.