Am Fr., 19. März 2021 um 09:04 Uhr schrieb Jakub T. Jankiewicz < [email protected]>:
> > > On Fri, 19 Mar 2021 00:17:59 -0400 > John Cowan <[email protected]> wrote: > > > > The good thing here is that we have a separation of concerns here: > > >>> > > > >>> > (1) Signifying that a file is to be parsed with a specific reader. > > >>> > (2) Extending the built-in reader. > > >>> > > >> > > >> The first is more general, if less convenient. > > >> > > > > > > There may be some misunderstanding. (1) is not an alternative to (2) > but > > > both go hand-in-hand. > > > > > > > For which use cases, other than changing the lexical syntax in the middle > > of a file (compilation unit), can #2 do the job but not #1? > > From what I see we don't need #2 at all. Because if we have #1 I can write > my > own reader that allow to extend itself. I can then package that reader as > extendable reader that allow of extension by set-syntax! this reader can be > specified by different spec that will use the #1. > This will break down as soon as a user wants to use two modules, say SRFI 300 and SRFI 400, whose specifications both include reader extensions. If the reader provided by SRFI 300 is disjoint from the one in SRFI 400, the user cannot easily use both syntaxes in the same file. It's not an automatic success, but (2) will at least show a way of how to produce a compatible family of readers. > I think that we don't need to extend built-in reader if we can change the > reader. User can specify library using extendable reader and use > set-special! > is his library. From what I see in this discussion is that we can't allow > to > extend built-in reader that's why we need to change the reader. > You use "extend" here in a different context from that in which I have used it.
