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:13 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:14 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:12 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:14 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:32 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:27 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:29 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:48 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:12 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 Lassi Kortela 09 Nov 2019 12:29 UTC

> 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.

Excellent argument for keyword syntax.

> 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)).

This is probably good too, as long as record field accessors look the
same to users in both cases.

Record field name clashes are one of the most famous gotchas in Haskell
(https://wiki.haskell.org/Name_clashes_in_record_fields) so it's nice to
have a way to deal with them.

> 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.

Hmm. Optional syntax in a standardized language is a bit odd IMHO, as if
the language could not make a decision to go one way or the other. In
SRFIs and individual implementations it's fine, as those often have to
make compromises for compatibility anyway.

The #: prefix is a bit heavy at 2 characters, and Chez uses it for
gensyms. Since many implementations use : prefix or suffix, it'd be nice
to have one of those (just my opinion, and syntax is always personal).

> 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.

This is probably a good idea for many Scheme implementations.