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)
|
Re: How and Why keyword arguments are useful or harmful?
John Cowan
(03 Nov 2019 22:08 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?
John Cowan
(03 Nov 2019 23:52 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)
|
Re: SRFI 177 as a dependency for keywords in other places
John Cowan
(03 Nov 2019 21:32 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
John Cowan
(09 Nov 2019 03:30 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)
|
Am Sa., 9. Nov. 2019 um 13:29 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>: > > > 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. Accessors are still ordinary identifiers bound to the accessor procedure. > > 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). Having to add a reader switch is certainly not optimal but would be necessary for strict R7RS-small compatibility. As a way out, we would have to amend R7RS-small first (I guess the Steering Commitee will have to be approached for that) so that SRFI 88 is not incompatble to R7RS-small's syntax for identifiers. > > 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.