Am Mi., 6. Nov. 2019 um 19:10 Uhr schrieb John Cowan <xxxxxx@ccil.org>: > > If you are willing to quote them when used as expressions (as in Kawa and Racket), it *is* easy, and I can add that to the lexical docket. But self-evaluation is the part that's going to require work. That's just one more case in the syntax expander (the other cases being characters, booleans, vectors, strings, bytevectors). > > On Wed, Nov 6, 2019 at 1:08 PM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote: >> >> Am Mi., 6. Nov. 2019 um 18:49 Uhr schrieb John Cowan <xxxxxx@ccil.org>: >> > >> > 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. >> >> Indeed; from a technical perspective, keywords are just interned strings. >> >> I don't think, though, that implementing keywords would be very hard >> for an individual Scheme system. One just needs to add flag to each >> interned symbol object denoting whether "symbol?" or "keyword?" >> registers true. And, of course, the reader has to be modified. But the >> overall compilation/evaluation strategy doesn't seem to be affected. >> Don't you think? >> >> Best, >> >> Marc >> >> > >> > >> > >> > >> > >> > 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/ >> >> >> >> -- >> 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/ -- 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/
