> > > > 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? >
(1), the proposed shebang-like line, is to signal the Scheme system that not the default reader but the reader exported by the library named on that line is to be used to parse the subsequent characters. If a Scheme implementation hits this line, it pauses to load the required library to get hand at the required reader and then uses that one to parse the rest of the file. The only issue could be dependency cycles but these are conceptually no different from cycles in other library dependencies. (2) actually defines what kind of object is understood by the system to act as a reader. It could (almost) be as simple as a procedure taking a character port and returning a Scheme datum (or syntax object). Because not everyone would like to write a reader from scratch, some way to extend the built-in reader (in a kind of object-oriented fashion?) would be needed. By extending, it is meant that a new reader object inheriting from the old is created. The new reader object won't affect parsing the file in which it is defined, only parsing of files, in which it is imported at the top. This resolves any phasing issues and decouples in the handling of one file the parsing from the evaluation.
