This page is part of the web mail archives of SRFI 1 from before July 7th, 2015. The new archives for SRFI 1 contain all messages, not just those from before July 7th, 2015.
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