Am Fr., 9. Dez. 2022 um 18:53 Uhr schrieb Lassi Kortela <lassi@lassi.io>: > > > 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.
So OBJECT here is a Scheme datum value that must not be confused with the unwritable object itself, right? I am wondering what the actual meaning of the OBJECT as a Scheme would be. For example, in Chez, (open-output-string) prints as #<output port string>, which would probably become #?(output port string) in your proposal. But interpreting the string "output port string" as a list of three symbols is not meaningful, is it? Or should it be #?"output port string"? > > 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. I guess that the native format of some (most?) implementations is just #<STRING>, where STRING is an (informal) string of characters. So does it really make sense to allow implementations to use their native format when the closing ">" has to be unambiguously parsable? > > 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> You cannot change <compound datum> because this can be a <datum>, and this is what the read procedure successfully parses (see 7.1.2 of the R7RS). > 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). If this is all that we want, then it will be enough to specify a new token #? whose semantics is the reader must signal an error when it reads it. Or do you want that #?(foo bar) signals an error, but #?(foo . . baz) not necessarily? > and export library procedure (write-unreadable-object object) which > writes that syntax. I should also mention an argument that speaks against inventing a new #? syntax: The #-lexical syntax-namespace is small and precious, so effectively doubling the syntax from #< to #< and #? for reader errors may be a bit costly.
