I agree that It Would Be Nice If.  But i simply do not believe that disjoint self-evaluating keywords will spread much beyond their current niche, nor that implementers will be willing to add them merely because R7RS-large says they should.  They have to go deep down into the compilation/evaluation strategy, not just a bag on the side like SRFI 170 where most systems have FFIs of some sort already.  If it comes to that, #:foo is no shorter than "foo", and will behave the same way if the implementation interns literal strings.





On Wed, Nov 6, 2019 at 5:49 AM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
Keyword read syntax would have more uses than just for keyword
arguments so it would be great if such a thing would be added to
R7RS-large:

"syntax-rules" macros match identifiers hygienically (and not the
underlying symbols using "eq?"/"equal?"). Sometimes, however, we want
something that is matched using "equal?". At the moment, we can only
use strings and numbers (and booleans and chars) in "syntax-rules"
macros for that.

For example, take a look at SRFI 165's "define-computation-type" and
especially the definition of "clause" there. There, I am using the
string "immutable" as a marker in the syntax, while an identifier
named immutable might have been more natural. Then, however, I would
have had to bind the identifier "immutable" and export it by SRFI 165.

Now, keywords would be matched using "eq?"/"equal?" by "syntax-rules"
macros. Thus, I could have simply used the keyword "immutable:" (or
":immutable" or "#'immutable" instead of the string "immutable" in
SRFI 165, which would have looked much nicer) if keywords were
available.

Another use case is the definition of record types (especially in the
context of inheritance):

(define-record-type <rtd> (make-record field1) (field1 getter setter))

Record field names like "field1" are matched hygienically as
identifiers in SRFI 150 and in R7RS-small (at least, this seems to
have been intended by WG1) and this has quite a number of advantages,
but when it comes to inheriting such records across libraries, it may
be more convenient if these record file names do not have to be ex-
and imported. Thus SRFI 150 allows to use strings instead (ugly!) but
proposes to use keywords (nicer!) when they are available when
non-hygienic matching is wanted:

(define-record-type <rtd> (make-record field1:) (field1: getter setter)).

~~~~

If we don't want to use (or cannot use) the prefix "#'" for keywords,
I would suggest adding SRFI 88 to R7RS-large. By default, the reader
would read "foo:" as an identifier (to preserve compatibility to
R7RS-small), but a reader flag to be introduced would switch the
reader to read "foo:" as the keyword "foo:" (whose stringified name is
"foo"). Furthermore "|foo:|" would be read as a symbol, "|foo|:" as a
keyword.

Thus, every Scheme port would get a flag (much like the case-folding
flag) that can be enabled to support keywords. When enabled on output
ports, keywords can be written. Symbols ending with ":" would be
written using the "|...|" syntax.

An extension of the port API would allow to get and set the
case-folding and other flags on ports programmatically.

-- Marc

Am So., 3. Nov. 2019 um 23:34 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:
>
> > I don't know.  All lexical syntax ideas are on a separate docket so that
> > people can fix their read implementations (which can be very complex) once
> > and only once rather than piecemeal.
>
> If R7RS-large gets keyword read syntax, then it can in principle omit
> the SRFI 177 hack of treating `foo:` and `:foo` symbols as keywords.



--
Prof. Dr. Marc Nieper-Wißkirchen

Universität Augsburg
Institut für Mathematik
Universitätsstraße 14
86159 Augsburg

Tel: 0821/598-2146
Fax: 0821/598-2090

E-Mail: xxxxxx@math.uni-augsburg.de
Web: www.math.uni-augsburg.de/alg/mitarbeiter/mnieper/