[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Regularization of Procedures in Scheme
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.
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.
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.
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.
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.
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.