Advanced file port operations: please review. John Cowan (01 Nov 2019 23:01 UTC)
Re: Advanced file port operations: please review. hga@xxxxxx (02 Nov 2019 00:14 UTC)
Re: Advanced file port operations: please review. John Cowan (02 Nov 2019 02:19 UTC)
Re: Advanced file port operations: please review. Shiro Kawai (02 Nov 2019 10:15 UTC)
Re: Advanced file port operations: please review. John Cowan (02 Nov 2019 14:36 UTC)
Port settings Lassi Kortela (02 Nov 2019 10:28 UTC)
Re: Port settings John Cowan (02 Nov 2019 14:00 UTC)
Re: Port settings Lassi Kortela (02 Nov 2019 14:13 UTC)
Re: Advanced file port operations: please review. hga@xxxxxx (02 Nov 2019 15:43 UTC)
Re: Advanced file port operations: please review. John Cowan (02 Nov 2019 18:15 UTC)
SRFI 177 as a dependency for keywords in other places Lassi Kortela (02 Nov 2019 23:00 UTC)
Re: SRFI 177 as a dependency for keywords in other places Marc Nieper-Wißkirchen (03 Nov 2019 08:33 UTC)
Keyword arguments in R7RS-large and SRFIs Lassi Kortela (03 Nov 2019 09:16 UTC)
Re: Keyword arguments in R7RS-large and SRFIs Amirouche Boubekki (03 Nov 2019 14:28 UTC)
Re: Keyword arguments in R7RS-large and SRFIs Lassi Kortela (03 Nov 2019 15:53 UTC)
Re: Keyword arguments in R7RS-large and SRFIs John Cowan (03 Nov 2019 19:30 UTC)
How and Why keyword arguments are useful or harmful? Amirouche Boubekki (03 Nov 2019 20:11 UTC)
Re: How and Why keyword arguments are useful or harmful? Amirouche Boubekki (03 Nov 2019 20:14 UTC)
Re: How and Why keyword arguments are useful or harmful? Lassi Kortela (03 Nov 2019 20:26 UTC)
Re: How and Why keyword arguments are useful or harmful? Lassi Kortela (03 Nov 2019 20:30 UTC)
R7RS-large keyowrds Lassi Kortela (03 Nov 2019 22:18 UTC)
Re: R7RS-large keyowrds John Cowan (03 Nov 2019 22:29 UTC)
Re: R7RS-large keyowrds Lassi Kortela (03 Nov 2019 22:34 UTC)
Re: R7RS-large keyowrds Marc Nieper-Wißkirchen (06 Nov 2019 10:49 UTC)
Re: R7RS-large keyowrds John Cowan (06 Nov 2019 17:49 UTC)
Re: R7RS-large keyowrds Marc Nieper-Wißkirchen (06 Nov 2019 18:08 UTC)
Re: R7RS-large keyowrds John Cowan (06 Nov 2019 18:10 UTC)
Re: R7RS-large keyowrds Marc Feeley (06 Nov 2019 18:16 UTC)
Re: R7RS-large keyowrds Marc Nieper-Wißkirchen (06 Nov 2019 18:17 UTC)
Re: R7RS-large keyowrds John Cowan (06 Nov 2019 20:23 UTC)
Re: R7RS-large keyowrds Marc Nieper-Wißkirchen (06 Nov 2019 18:16 UTC)
Re: R7RS-large keyowrds Marc Feeley (06 Nov 2019 17:59 UTC)
Re: R7RS-large keyowrds Lassi Kortela (09 Nov 2019 12:29 UTC)
Re: R7RS-large keyowrds Marc Nieper-Wißkirchen (09 Nov 2019 12:53 UTC)
Re: How and Why keyword arguments are useful or harmful? Amirouche Boubekki (04 Nov 2019 03:31 UTC)
Re: How and Why keyword arguments are useful or harmful? Amirouche Boubekki (04 Nov 2019 04:10 UTC)
Re: How and Why keyword arguments are useful or harmful? Amirouche Boubekki (04 Nov 2019 03:43 UTC)
Re: How and Why keyword arguments are useful or harmful? Marc Nieper-Wißkirchen (06 Nov 2019 13:25 UTC)
When is a feature necessary Lassi Kortela (03 Nov 2019 22:06 UTC)
Re: When is a feature necessary Lassi Kortela (03 Nov 2019 22:13 UTC)
Re: SRFI 177 as a dependency for keywords in other places Marc Nieper-Wißkirchen (06 Nov 2019 10:21 UTC)
Re: SRFI 177 as a dependency for keywords in other places Lassi Kortela (09 Nov 2019 11:55 UTC)
Re: SRFI 177 as a dependency for keywords in other places Marc Nieper-Wißkirchen (09 Nov 2019 13:40 UTC)
Re: SRFI 177 as a dependency for keywords in other places Marc Nieper-Wißkirchen (09 Nov 2019 13:13 UTC)

Re: R7RS-large keyowrds Marc Nieper-Wißkirchen 06 Nov 2019 18:16 UTC

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/