Email list hosting service & mailing list manager

Unicode lambda Lassi Kortela (12 May 2019 10:19 UTC)
Re: Unicode lambda Shiro Kawai (12 May 2019 11:18 UTC)
Re: Unicode lambda Lassi Kortela (12 May 2019 11:40 UTC)
Re: Unicode lambda Lassi Kortela (12 May 2019 11:50 UTC)
Re: Unicode lambda Shiro Kawai (12 May 2019 12:06 UTC)
Re: Unicode lambda Marc Nieper-Wißkirchen (12 May 2019 12:11 UTC)
Re: Unicode lambda Lassi Kortela (12 May 2019 12:23 UTC)
Re: Unicode lambda Lassi Kortela (12 May 2019 13:23 UTC)
Re: Unicode lambda Lassi Kortela (12 May 2019 13:46 UTC)
Re: Unicode lambda John Cowan (12 May 2019 14:20 UTC)
Re: Unicode lambda Lassi Kortela (12 May 2019 14:38 UTC)
Re: Unicode lambda Lassi Kortela (12 May 2019 14:55 UTC)
Re: Unicode lambda John Cowan (12 May 2019 15:00 UTC)
Re: Unicode lambda Lassi Kortela (12 May 2019 15:20 UTC)
Re: Unicode lambda Shiro Kawai (12 May 2019 18:42 UTC)
Re: Unicode lambda Lassi Kortela (12 May 2019 19:43 UTC)
Re: Unicode lambda John Cowan (12 May 2019 22:29 UTC)
Re: Unicode lambda Shiro Kawai (13 May 2019 10:48 UTC)
Re: Unicode lambda Lassi Kortela (14 May 2019 08:25 UTC)
Re: Unicode lambda Marc Nieper-Wißkirchen (14 May 2019 08:50 UTC)
Re: Unicode lambda Lassi Kortela (14 May 2019 10:10 UTC)
Re: Unicode lambda Lassi Kortela (14 May 2019 10:59 UTC)
Re: Unicode lambda Lassi Kortela (14 May 2019 12:35 UTC)
Re: Unicode lambda Lassi Kortela (14 May 2019 13:09 UTC)
Re: Unicode lambda Lassi Kortela (14 May 2019 14:04 UTC)
Re: Unicode lambda Shiro Kawai (14 May 2019 19:18 UTC)
Re: Unicode lambda Vincent Manis (14 May 2019 22:01 UTC)
Re: Unicode lambda Lassi Kortela (20 May 2019 09:21 UTC)
Re: Unicode lambda Marc Nieper-Wißkirchen (21 Oct 2019 14:20 UTC)
Re: Unicode lambda Shiro Kawai (21 Oct 2019 17:19 UTC)
Re: Unicode lambda John Cowan (21 Oct 2019 17:39 UTC)
Re: Unicode lambda Marc Nieper-Wißkirchen (21 Oct 2019 18:43 UTC)
Re: Unicode lambda John Cowan (21 Oct 2019 23:27 UTC)
Encoding declarations Lassi Kortela (22 Oct 2019 08:39 UTC)
Re: Encoding declarations John Cowan (22 Oct 2019 20:52 UTC)
#! directives, general and specific Lassi Kortela (22 Oct 2019 09:11 UTC)
Re: #! directives, general and specific John Cowan (22 Oct 2019 20:27 UTC)
Re: #! directives, general and specific Lassi Kortela (22 Oct 2019 20:43 UTC)
Re: Unicode lambda Marc Nieper-Wißkirchen (13 May 2019 08:50 UTC)
Re: Unicode lambda Lassi Kortela (13 May 2019 10:27 UTC)
Re: Unicode lambda Per Bothner (12 May 2019 14:17 UTC)
Re: Unicode lambda Peter (12 May 2019 15:06 UTC)

Re: Unicode lambda Lassi Kortela 14 May 2019 13:08 UTC

More sketching:

- An implementation would start reading a file with its default
implementation-defined syntax (RnRS + maybe extensions and deviations).

- When it encounters the standard #!r6rs directive, or a proposed #!r7rs
directive, it sets its read syntax equivalent to that Scheme report with
no extensions (or causes an error if it doesn't support that syntax).

- When it encounters #!(srfi 234 [options...]) it modifies the current
read syntax by ensuring SRFI 234 is turned on. (If SRFI 234 does not
specify any syntax changes, this is an error. If it specifies other
things in addition to syntax, e.g. procedures or variables, those are
not imported or otherwise affected by the #!(srfi ...) directive, only
the syntax is. Any procedures must be imported separately with ordinary
import statements.) If SRFI 234 was already turned on but the options
given are different from the previous ones, the options are changed to
the new ones (i.e. the effect is the same as first turning off SRFI 234
syntax and then turning it on again with the new options).

- When the reader encounters #!(no-srfi 234) it ensures SRFI 234 changes
are turned off in the read syntax. Again, if SRFI 234 specifies other
things in addition to syntax, those are not affected (symbols are not
unimported, etc.)

I don't know whether it makes sense to keep adding new #!rNrs
identifiers after #!r6rs (#!r7rs, maybe #!r7rs-large, #!r8rs, etc.)
Would it be better to have something like #!(scheme 7) or #!(scheme 8)?
Also Racket has things like "#lang racket/base". A more general

     #!(lang whatever <options...>)

might make sense. If we go down this road we should take some time to
explore how different scenarios would play out. John and others had
already done some thinking mechanisms to support non-Scheme source
languages and translate to Scheme.

Finally, for context, here's the relevant part of R6RS: "An
implementation must not extend the lexical or datum syntax in any way,
with one exception: it need not treat the syntax #!⟨identifier⟩, for any
⟨identifier⟩ (see section 4.2.4) that is not r6rs, as a syntax
violation, and it may use specific #!-prefixed identifiers as flags
indicating that sub- sequent input contains extensions to the standard
lexical or datum syntax. The syntax #!r6rs may be used to signify that
the input afterward is written with the lexical syn- tax and datum
syntax described by this report. #!r6rs is otherwise treated as a
comment; see section 4.2.3."