Various people wrote:
#!/usr/bin/env scheme-script
#!(import (reader expandable))
(set-special! "#:" 'keyword)
The difficulty with this is phasing, the same as with SRFI 10. You are using either a compile-time action (if set-special! is a macro) or a runtime action (if set-special! is a procedure) to affect read-time behavior. In particular, compilers which read a whole file, like Chicken, before compiling any of it cannot make these things happen.
I was also asking about Reader macros in Common Lisp by the person that was
answered my old question on StackOverflow and it seems that common lisp have
single global variable for the reader, and it don't give any issues.
That is partly because *readtable* is saved by `load` and `compile-file` using a dynamically scoped variable and then restored after the file has been loaded or compiled. As a result, any changes made to the readtable while processing the file are in effect only for the rest of that file.
#!(import (reader expandable))
than library creators can write new languages in form of reader and it will
work similar to Racket languages, which may be very cool.
Yes, and for that reason I would prefer to use the keyword "lang". There is no reason for the input language accepted by the library to have any syntactic resemblance to Scheme at all: Racket's "#lang algol60" (note the different syntax; I would like to keep ours separate) has a reader that compiles Algol 60 into equivalent Scheme and returns that. Similar readers are available for C, Datalog, OCaml, and many other languages.
Racket requires its readers to return syntax objects rather than plain S-expressions, because syntax objects in Racket carry information about the source line and column, so that error messages can be returned in terms of the original line and column rather than the Scheme translation. I'm interested in whether people think this is worth the extra complexity. I don't know whether there have to be syntax objects "all the way down" as in (datum->syntax (map datum->syntax '(1 2 3)))" or not as in "(datum->syntax (list 1 2 3))".
> 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. I wish we had a Scheme reader that is deliberately somewhat forgiving: it might return a specialized object for undefined syntax like "3+4i+5j+6k" or "#oid2.1.1" or "#u128(10 20 30 40 50)", for example. That allows readers that just want to handle small deviations from Scheme to do a trivial tree walk and replace.
> The second point is much harder and we should focus on the semantics and
> not on the exact API first.
However, the #! approach has no phasing problems, so its semantics is actually simpler.
My .sigs are from my large and miscellaneous reading both on and off the net.
Occasionally I hear one viva voce or make one up (without attribution,
of course). I try to stay within the McQuary limit, but sometimes fail,
as in this case. In general, the quotes are chosen at random by a script
from <
http://vrici.lojban.org/~cowan/signatures>, but sometimes I choose one
on purpose. I've been collecting and using them for 30+ years.