Email list hosting service & mailing list manager

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:08 UTC

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/