Re: Regularization of Procedures in Scheme

[William Clinger <will@fog.cs.uoregon.edu>]

Another response to Morry's proposal.

But first a response to Pavel:
- I prefer (string #\^ c)
  to (let ((s (make-string 2 #\^))) (string-set! s 1 c) s).
- For reasons of efficiency, I would like to keep gratuitous polymorphism
  out of the standard Scheme procedures.  For example, if VECTOR-REF had
  to work on both vectors and strings, it probably wouldn't be coded
  in-line (as it and STRING-REF are in MacScheme).  Furthermore a type/
  representation inference system probably couldn't infer enough to be
  useful when it saw a use of VECTOR-REF.  And what's the point of giving
  up this efficiency?  It is very rare to know that something is either a
  vector or a string but not to know which, so making VECTOR-REF work on
  both vectors and strings seems gratuitous.
- A hand-coded SUBLIST might be faster (e.g. you could schedule a CAR so
  that a cache miss would result in the load being overlapped with the
  storage allocation for a CONS), but I don't think such arguments should
  determine what goes in the report and what goes in the yellow pages
  since there's nothing to stop implementations from providing custom
  versions of procedures that appear in the yellow pages if they feel
  the custom versions are needed for efficiency.  I'd rather add Chris
  Hanson's 75 or so string procedures to the yellow pages than argue
  about which 5 or so are the most important to add to the report.
  Maybe we should organize part of the yellow pages into auxiliary
  reports for each major data type, with the code as an appendix.

Response to Morry:

- The names of the string-fill! and vector-fill! procedures should include
  an exclamation point.

Non-controversial #1:
  I object to make-list, list-fill!, list-set!, and list-copy on the
  grounds that they are useful only for side-effect-full programming on
  lists, which I claim is an unusual style that the standard should not
  encourage.  The corresponding procedures for strings and vectors are
  less objectionable because side-effect-full programming on strings
  and vectors is normal in Scheme.  The procedures whose absence from
  the report are most noticeable to me are string-set and vector-set
  (without the exclamation marks); these are analogues of cons, used
  for side-effect-free programming with strings and vectors. By the
  way, string-set and vector-set show why e.g. (vector-set! v i e)
  should not be required to return e.  Implementations should be allowed
  to return v for compatibility with vector-set, as MacScheme does.

Controversial #1:
  MacScheme also supplies proper-list?, which returns #f on circular
  lists as well as on lists terminated by something other than the
  empty list.  The syntax-checking pass of the compiler uses it a lot.

Controversial #2:
  I agree with Pavel.  My inclination is not to generalize apply until
  we understand where we're going with optional arguments and such.  The
  connection is that optional arguments are now implemented using rest
  arguments, which are wired in as lists, which end up being the most
  common final argument to apply.  This was probably a mistake, which
  will be hard enough to undo even without further complications.

Controversial #3:
  I oppose b) because there is no particular reason for the result of
  string-map, say, to be a string rather than a vector.  If we're going
  to generalize, let's do it right with c).  I propose, however, that
  someone just post the polymorphic procedures list-map, string-map,
  and vector-map to the yellow pages.  They're trivial to write poorly
  (just convert all the arguments to lists and call map) and probably
  impossible to write efficiently except for special cases.  Similarly
  for the highly polymorphic version of for-each.

Controversial #6:
  I agree with Pavel: these should be in the yellow pages rather than the
  report.  By the way, I think the predicate argument should be the first.

Peace, Will