Email list hosting service & mailing list manager


The "linear update" issue Lars Thomas Hansen 04 Feb 1999 20:17 UTC

No comments have so far been made on Olin's (silent) change in the
meanings of some nonstandard but common procedures with names ending
with `!'.

I am concerned about procedures like APPEND! and REVERSE!, which in
existing systems have imperative semantics but which in SRFI-1 do not.
APPEND! and REVERSE! as specified in SRFI-1 are compatible neither with
Chez Scheme (as specified in the First Edition of Dybvig's book) nor MIT
Scheme (as specified in the version 7.3 online documentation), because
those specifications *guarantee* that the cells for the result are the
cells from the input lists for these procedures.

I dislike the co-opting of these procedures because I actually use them
for list operations that guarantee the preservation of shared structure,
and I'd like to be able to continue to do so.  It is a useful, albeit
typically imperative, programming technique, and I humbly think SRFI-1
should acknowledge this by supporting it.

(I am also worried that the `!' suffix, which so far has implied
imperative update, is suddenly given a second meaning which, due to the
continued existence of set-cdr!, vector-set!, and so on, must coexist
with the original meaning, thus creating needless confusion and
uncertainty about which procedures might be imperative and which might
be linear-update, but this is a secondary issue.)

I'm all in favor of enabling compilers to take advantage of
linear-update operations, but I do not think that working code and
implementations should be broken for this reason.  It is better to
introduce new names for procedures with new meanings, rather than
changing the meanings of existing procedures.

Thus, I urge that Olin's point 8, "Should we provide both
reliably-destructive and linear-update (potentially destructive)
procedure variants?" be answered in the affirmative.

As for a naming scheme, I'm just as happy writing LINEAR-APPEND as
APPEND+.  I note that a name like APPEND!? is suggestive of the intent
of the specification :-)

--lars