Re: Programmer-defined data types, version 2

[Andy Cromarty <andy@ads.com>]

I like Pavel's record operators proposal. 

Reading it, I had two thoughts about additional capabilities that
we may wish to consider.  (I feel no religious fervor regarding
this two proposals; I'm simply suggesting them for joint consideration.)

1. It would be useful to have an "external representation" for records
   analogous to those available for lists and vectors:

	lists:	 `( ... ) 
	vectors: '#( ...)
	strings: " ... " 
	records: ???

   This seems especially valuable since it takes a lot of legwork to
   create a single record instance compared to the cost of typing,
   say, '(a b c), or for that matter (list 'a 'b 'c).  An external
   representation could be helpful where the programmer wishes to
   initialize variables within a lexical closure and as a means of
   portably transferring record instances between different Scheme
   images or implementations without having to generate Scheme source
   code on the fly to reproduce those instances.  (I assume Pavel's
   note about not proposing "any general macro for definition of
   record types" was not intended to refer to external representations
   of record instances.)

   I realize that this risks reopening the debate about reserving
   everyone's favorite characters, but as a strawman, we might use
   something like '#{ "TYPENAME" ... }, with appropriately fleshing out
   of details.

2. As I read Pavel's proposal, records are polymorphic but of fixed
   extent.  But there are cases where it is useful to be able to extend
   set of fields of a record dynamically.  For example, we might
   wish to use records to implement an "object-oriented" sublanguage
   and use a separate field for each method; fixed-extent records 
   would not allow extension of the set of methods once a type had
   been declared.  (Of course, there are ways around this, e.g. naming
   one field "methods" and holding some dynamic-extent data structure
   like a list in that field, but this seems a little like the
   observation that "you can implement LISP lists using FORTRAN 
   arrays"---true but not very interesting.)  Fixed extent does feel
   like a little bit of a limitation of the potential of records as
   a data structure.  Perhaps we should consider a (non-essential?)
   procedure that extends the set of fields of a record type 
   (non-essential because it could complicate things and slow performance
   for some implementation techniques).

					asc