Email list hosting service & mailing list manager

Fate of this SRFI Daphne Preston-Kendal (09 Apr 2023 12:06 UTC)
Re: Fate of this SRFI Arthur A. Gleckler (09 Apr 2023 17:14 UTC)
Re: Fate of this SRFI Lassi Kortela (20 Apr 2023 12:26 UTC)
Ramifications for the future Lassi Kortela (20 Apr 2023 13:18 UTC)

Ramifications for the future Lassi Kortela 20 Apr 2023 13:18 UTC

BTW the SRFI has something to say about the future standardization of
customizable writers.

Common Lisp lets users define printers for custom data types by
specializing PRINT-OBJECT (http://clhs.lisp.se/Body/f_pr_obj.htm). A
common way to print is to use the helper macro PRINT-UNREADABLE-OBJECT
(http://clhs.lisp.se/Body/m_pr_unr.htm). Both PRINT-OBJECT and
PRINT-UNREADABLE-OBJECT let the user write arbitrary characters to the
output stream.

Scheme has generally endeavored to clean up Lisp semantics, and we
should do that here. Scheme's equivalent of PRINT-OBJECT should not be a
procedure that writes arbitrary characters as a side effect, but a pure
function that returns a standard object to be printed in place of the
exotic object. (The present SRFI will define a standard
`unreadable-object` type to represent many exotic objects for read and
write purposes.)

Semantic cleanup generally yields positive second-order effects. In this
case, one such effect is that dealing with objects instead of characters
lets us `write` and `read` objects to and from binary ports, as well as
textual ports that use non-Scheme syntax. For example, it makes sense to
`read` and `write` a JSON or YAML or ASN.1 port. These ports may not
support the full range of Scheme data types, but if you restrict
yourself to the supported types the API is intuitive. If we define an
ASN.1 data type for unreadable objects, then any code writing those
objects using Scheme syntax will transparently work with ASN.1 syntax as
well.

TL;DR The "lexical" layer and the "object" layer are mixed freely in
Common Lisp; Scheme should separate them; This SRFI can be a first step.