Am Do., 18. März 2021 um 21:10 Uhr schrieb John Cowan <[email protected]>:
>
>
> 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.
>
This has already be retracted by Jakub.
#!(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.
>
Whether "#!(import (...))" or "#lang algol60" doesn't make any difference
about the kind of language being accepted. It is more about whether just
the reader or more of the compiler/interpreter pipeline will be affected by
such switches.
> 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))".
>
Given the following macro
(define-syntax foo
(lambda (x)
(syntax-case x ()
(() (list #'list 1 2 3)))))
the syntax object returned by its transformer would most likely only look
like "(datum->syntax (list 1 2 3))". It wouldn't make much of a difference,
though, because of the way syntax objects are unpacked (and the wrap is
pushed towards the leaves).
Unsyntax contains a reader that returns the Unsyntax version of syntax
objects exactly to be able to communicate line and column numbers in case
of errors.
>
> > 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.
>
There may be some misunderstanding. (1) is not an alternative to (2) but
both go hand-in-hand.
