Email list hosting service & mailing list manager

Unreadable Objects: current status and where to go Lassi Kortela (09 Dec 2022 17:12 UTC)
Re: Unreadable Objects: current status and where to go Marc Nieper-Wißkirchen (09 Dec 2022 17:30 UTC)
Re: Unreadable Objects: current status and where to go Lassi Kortela (09 Dec 2022 17:53 UTC)
Re: Unreadable Objects: current status and where to go Lassi Kortela (09 Dec 2022 18:09 UTC)
Re: Unreadable Objects: current status and where to go Marc Nieper-Wißkirchen (09 Dec 2022 18:33 UTC)
Re: Unreadable Objects: current status and where to go Lassi Kortela (09 Dec 2022 19:13 UTC)
Re: Unreadable Objects: current status and where to go Marc Nieper-Wißkirchen (09 Dec 2022 19:20 UTC)
Re: Unreadable Objects: current status and where to go Lassi Kortela (09 Dec 2022 19:38 UTC)
Re: Unreadable Objects: current status and where to go Arthur A. Gleckler (09 Dec 2022 20:14 UTC)
Re: Unreadable Objects: current status and where to go Marc Nieper-Wißkirchen (09 Dec 2022 20:42 UTC)
Re: Unreadable Objects: current status and where to go Lassi Kortela (10 Dec 2022 13:35 UTC)
Re: Unreadable Objects: current status and where to go John Cowan (09 Dec 2022 19:22 UTC)
Re: Unreadable Objects: current status and where to go Marc Feeley (09 Dec 2022 19:01 UTC)

Re: Unreadable Objects: current status and where to go Lassi Kortela 09 Dec 2022 17:53 UTC

> If you stick to #<...> (the original domain of SRFI 243), you can
> really only make one effective constraint, namely the following:
>
> "A Scheme implementation supports SRFI 243 if its standard reader (and
> its read/get-datum procedure(s)) signal an error/raise an exception
> when the token #< is read."
>
> (Everything else is non-normative.)  Given this specification, R6RS
> systems would all support SRFI 243 and probably most R7RS systems as
> well.

It might make sense to specify a procedure,

(write-unreadable-object object)

that writes `object` using the customary notation of the Scheme
implementation.

For implementations using #? it would be as simple as:

(define (write-unreadable-object object)
   (write-string "#?")
   (write object))

For implementations using #< it could be something like:

(define (write-unreadable-object object)
   (write-string "#<")
   (write (if (or (null? object)
                  (pair? object))
              object
              (list object)))
   (write-string ">"))

or:

(define (write-unreadable-object object)
   (write-string "#<")
   (cond ((list? object)
          (for-each (lambda (item)
                      (write-string " ")
                      (write item))
                    object))
         (else
          (write-string " ")
          (write object)))
   (write-string " >"))

or whatever else preserves the closing ">" as unambiguous.

Given the chaotic situation in the field, it's probably not worthwhile
to attempt to write any readers that skip #<...>, but the above solution
can unify #<...> and #?datum from the Scheme programmer's (and Scheme
_implementation_ programmer's) point of view, and paves the way for
standardizing well-formed unreadable-object syntax in the future.

> If you move to #?, the focus of SRFI 243 seems to change considerably.
> Could you write down the intended normative part in a few sentences of
> such a version of SRFI 243?

Change the RnRS grammar so <compound datum> includes <unreadable>

where <unreadable> == "#?" <datum>

When `(read)` reads <unreadable>, it raises an error (we could specify a
standard subtype of read-error for this purpose, call it e.g.
unreadable-object-error).

and export library procedure (write-unreadable-object object) which
writes that syntax.