Am So., 11. Okt. 2020 um 20:22 Uhr schrieb Wolfgang Corcoran-Mathe
<xxxxxx@sigwinch.xyz>:

> > In R7RS they could have different names. (scheme bytestring-notation)
> > and (scheme bytestring), for instance. (But does cond-expand even make
> > sense for reader notation? Surely it’d cause a reader error in any
> > case?)

That doesn't help outside R7RS-large.

> Right.  There's no reason a split couldn't be made when/if the SRFI is
> added to R7RS-large.  And yes--doesn't cond-expand with lexical syntax
> get us into the abyss of phasing, anyway?

I don't understand the latter comment (apart from the fact that
phasing does not have to be viewed as an abyss...). We are not talking
about loading a reader extension at library load time (this would, in
fact, touch on phasing issues), but about statically checking whether
such a reader extension is available. As in:

(cond-expand
 ((library (srfi 207))
  (include "file-using-u8-notation.scm"))
 (else
  (include "unreadable-file.scm"))))

In this case, "unreadable-file.scm" could be generated from
"file-using-u8-notation.scm" by some tool that expands the SRFI 207
notation. One SRFI 207 systems, I have the advantage with the above
cond-expand that I can edit the master file and can experiment with
the result immediately without regenerating "unreadable-file.scm".