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 12:55 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>: > > Thanks again for the thoughtful contrarian arguments Marc. Thanks; the ability to use keyword arguments (in a portable way) would deeply change how we program in Scheme and design our procedures. At the moment, we may have use cases like some procedures in SRFI 170 in mind, but when keyword arguments are generally available, people will also start to use them in case where they have used positional or optional arguments previously (e.g. in procedures like R7RS-small's "member"; maybe even in procedures with many arguments like SRFI 1's "unfold"). Thus endorsing a SRFI like SRFI 177 as a part of R7RS-large, would cause the core language (its canonical idioms) to change. You have yet failed to convince me that this fundamental change is necessarily a good one and widely accepted; until then I will remain a critic. ;) Compare this with, say, your SRFI 169. Some will like it, some won't, it may be included in R7RS-large or it may not, it may even become part of R8RS, whatever. But it won't change what I would call the core of the language. To give another example: Python has built-in dictionaries, so they are used ubiquitary (even in other core constructs like class dictionaries, etc.). Now think of a language addition to Scheme that deeply integrates hash tables into the language (by providing some syntactic sugar, by giving hash tables read and write syntax, etc.). For sure, this would change how Scheme would be used everyday (why use plists or alists when you have simple and fast hash table syntax?). I'm not saying that such an addition is necessarily bad, but it should only come after giving it a lot of thought (and a lot of time to think about) as it would be some fundamental change. Such a change should probably happen in the core language (R?RS-small) and not in the extension of the core language (R?RS-large). > > >> I was referring to the idea that the main advantage of keyword > >> arguments is that parameters can be added to API calls in a > >> backward-compatible way. > > > > I think the main advantage is readability. You can just as well add > > ordinary unnamed arguments at the end of an ordinary lambda-list, but at a > > high cost in readability. > > To me the best thing is that it's easy for users. You can add arguments > and move on to more other work without having these deliberations each time. Most of one's programming time (when programming libraries) should go into the design of the API and not into the actual programming work. (A bit exaggerated, for sure, but you know what I mean.) A similar thing is true when specifying an API. Thus, having the ability of adding keyword arguments at the end of argument lists without having to think too much, it not necessarily a good thing. I agree, though, that it makes sense if the language hints at some preferred ways to solve this problem. > > The most hardcore Haskellers might prefer to make a composable DSL out > of everything. I'd agree in many cases, but should we really make a new > DSL for every library with a `find`- or `open`-style procedure? Thanks for Scheme's macro system, the situation is much better than with Haskell. In Scheme, you can spec a DSL for a DSL generator. :) In some sense, the proposal I made in a reply to one of John's posts, namely having an opaque settings type (and some syntax that allows one to easily create such settings types) can be seen as some (very limited) form of DSL that solves the "keyword argument" problem. (One advantage of that solution > > Looking at prior art from Common Lisp and Emacs, the no-effort solution > of keywords tends to be at least 80% as good as a tailor-made solution > would be (look at some procedures with keyword/optional args and imagine > replacing them with a record or DSL). Scheme is neither Common Lisp, not Elisp. The syntax may be the same but they are very different languages. (The whole hygiene discussion we have had is a symptom of this; just moving Common Lisp syntax to the Scheme world does not necessarily lead to clear and uniform semantics.) Marc