SRFI 197: Threading Macros
Arthur A. Gleckler
(09 Jun 2020 03:41 UTC)
|
First comments
Marc Nieper-Wißkirchen
(09 Jun 2020 06:48 UTC)
|
Re: First comments
Linus Björnstam
(09 Jun 2020 07:27 UTC)
|
Re: First comments
Marc Nieper-Wißkirchen
(09 Jun 2020 08:30 UTC)
|
Re: First comments
Adam Nelson
(09 Jun 2020 13:25 UTC)
|
Re: First comments
Marc Nieper-Wißkirchen
(09 Jun 2020 14:06 UTC)
|
Re: First comments
Lassi Kortela
(09 Jun 2020 14:12 UTC)
|
Re: First comments
Marc Nieper-Wißkirchen
(09 Jun 2020 15:28 UTC)
|
Re: First comments
Marc Nieper-Wißkirchen
(09 Jun 2020 16:05 UTC)
|
Re: First comments
Adam Nelson
(09 Jun 2020 16:15 UTC)
|
Re: First comments
Marc Nieper-Wißkirchen
(09 Jun 2020 16:22 UTC)
|
Re: First comments
Arne Babenhauserheide
(09 Jun 2020 17:03 UTC)
|
Re: First comments
Adam Nelson
(09 Jun 2020 17:16 UTC)
|
Re: First comments
Marc Nieper-Wißkirchen
(09 Jun 2020 17:22 UTC)
|
Re: First comments
Lassi Kortela
(09 Jun 2020 17:31 UTC)
|
Re: First comments
Marc Nieper-Wißkirchen
(09 Jun 2020 17:40 UTC)
|
Re: First comments
Arne Babenhauserheide
(09 Jun 2020 22:19 UTC)
|
Re: First comments
Marc Nieper-Wißkirchen
(10 Jun 2020 06:16 UTC)
|
Re: First comments
Linus Björnstam
(10 Jun 2020 07:17 UTC)
|
Re: First comments
Marc Nieper-Wißkirchen
(10 Jun 2020 07:38 UTC)
|
Re: First comments
Linus Björnstam
(10 Jun 2020 08:21 UTC)
|
Re: First comments
Marc Nieper-Wißkirchen
(10 Jun 2020 08:42 UTC)
|
Re: First comments
Linus Björnstam
(15 Jun 2020 19:50 UTC)
|
Re: First comments
Marc Nieper-Wißkirchen
(15 Jun 2020 20:09 UTC)
|
Re: First comments
Linus Björnstam
(16 Jun 2020 11:39 UTC)
|
Re: First comments
Arne Babenhauserheide
(10 Jun 2020 07:53 UTC)
|
Re: First comments
Marc Nieper-Wißkirchen
(10 Jun 2020 08:04 UTC)
|
Re: First comments
Marc Nieper-Wißkirchen
(09 Jun 2020 17:44 UTC)
|
Re: First comments
Adam Nelson
(09 Jun 2020 17:46 UTC)
|
Re: First comments
Marc Nieper-Wißkirchen
(09 Jun 2020 17:49 UTC)
|
Re: First comments
Arvydas Silanskas
(09 Jun 2020 07:40 UTC)
|
Named procedure; RE: SRFI 197: Threading Macros
Arne Babenhauserheide
(09 Jun 2020 13:40 UTC)
|
Re: Named procedure; RE: SRFI 197: Threading Macros
Adam Nelson
(09 Jun 2020 13:48 UTC)
|
Re: Named procedure; RE: SRFI 197: Threading Macros
Marc Nieper-Wißkirchen
(09 Jun 2020 14:09 UTC)
|
Re: Named procedure; RE: SRFI 197: Threading Macros
hga@xxxxxx
(09 Jun 2020 14:16 UTC)
|
Re: Named procedure; RE: SRFI 197: Threading Macros
Lassi Kortela
(09 Jun 2020 14:42 UTC)
|
Re: Named procedure; RE: SRFI 197: Threading Macros
Marc Nieper-Wißkirchen
(09 Jun 2020 14:48 UTC)
|
Re: Named procedure; RE: SRFI 197: Threading Macros
hga@xxxxxx
(09 Jun 2020 15:10 UTC)
|
Re: Named procedure; RE: SRFI 197: Threading Macros
Marc Nieper-Wißkirchen
(09 Jun 2020 15:25 UTC)
|
Re: Named procedure; RE: SRFI 197: Threading Macros
Arne Babenhauserheide
(09 Jun 2020 15:47 UTC)
|
Re: Named procedure; RE: SRFI 197: Threading Macros
Marc Nieper-Wißkirchen
(09 Jun 2020 15:58 UTC)
|
Re: Named procedure; RE: SRFI 197: Threading Macros
Adam Nelson
(09 Jun 2020 16:21 UTC)
|
Re: Named procedure; RE: SRFI 197: Threading Macros
Marc Nieper-Wißkirchen
(09 Jun 2020 16:46 UTC)
|
Re: Named procedure; RE: SRFI 197: Threading Macros
Adam Nelson
(09 Jun 2020 17:13 UTC)
|
Re: Named procedure; RE: SRFI 197: Threading Macros
Marc Nieper-Wißkirchen
(09 Jun 2020 17:35 UTC)
|
Re: Named procedure; RE: SRFI 197: Threading Macros
John Cowan
(11 Jun 2020 00:59 UTC)
|
Re: Named procedure; RE: SRFI 197: Threading Macros
hga@xxxxxx
(09 Jun 2020 16:58 UTC)
|
Re: Named procedure; RE: SRFI 197: Threading Macros
Lassi Kortela
(09 Jun 2020 17:00 UTC)
|
Re: Named procedure; RE: SRFI 197: Threading Macros
Arne Babenhauserheide
(09 Jun 2020 17:00 UTC)
|
Re: Named procedure; RE: SRFI 197: Threading Macros
Marc Nieper-Wißkirchen
(09 Jun 2020 15:17 UTC)
|
Usecase: chaining operations after "optionals"
Arne Babenhauserheide
(09 Jun 2020 17:18 UTC)
|
Re: Usecase: chaining operations after "optionals"
Adam Nelson
(09 Jun 2020 17:24 UTC)
|
Re: Usecase: chaining operations after "optionals"
Marc Nieper-Wißkirchen
(09 Jun 2020 17:48 UTC)
|
Re: Usecase: chaining operations after "optionals"
Adam Nelson
(09 Jun 2020 17:55 UTC)
|
Re: Usecase: chaining operations after "optionals"
Marc Nieper-Wißkirchen
(09 Jun 2020 19:11 UTC)
|
Re: Usecase: chaining operations after "optionals"
Arne Babenhauserheide
(09 Jun 2020 22:08 UTC)
|
Re: Usecase: chaining operations after "optionals"
Marc Nieper-Wißkirchen
(10 Jun 2020 06:11 UTC)
|
Re: Usecase: chaining operations after "optionals"
Arne Babenhauserheide
(10 Jun 2020 08:03 UTC)
|
Re: Usecase: chaining operations after "optionals"
Marc Nieper-Wißkirchen
(10 Jun 2020 08:10 UTC)
|
Association list utilities
Lassi Kortela
(10 Jun 2020 08:24 UTC)
|
Re: Association list utilities
Marc Nieper-Wißkirchen
(10 Jun 2020 08:30 UTC)
|
Re: Association list utilities
Lassi Kortela
(10 Jun 2020 08:49 UTC)
|
Re: Association list utilities
Marc Nieper-Wißkirchen
(10 Jun 2020 09:29 UTC)
|
Re: Association list utilities Lassi Kortela (10 Jun 2020 09:59 UTC)
|
Re: Association list utilities
Marc Nieper-Wißkirchen
(10 Jun 2020 10:09 UTC)
|
Re: Association list utilities
Lassi Kortela
(10 Jun 2020 10:37 UTC)
|
Re: Association list utilities
Arne Babenhauserheide
(10 Jun 2020 10:33 UTC)
|
Re: Usecase: chaining operations after "optionals"
Arne Babenhauserheide
(10 Jun 2020 09:16 UTC)
|
Re: Usecase: chaining operations after "optionals"
Marc Nieper-Wißkirchen
(10 Jun 2020 09:19 UTC)
|
Re: Usecase: chaining operations after "optionals"
Lassi Kortela
(10 Jun 2020 09:29 UTC)
|
Re: Usecase: chaining operations after "optionals"
Marc Nieper-Wißkirchen
(10 Jun 2020 09:42 UTC)
|
More on association lists (and other key-value collections)
Lassi Kortela
(10 Jun 2020 10:16 UTC)
|
Re: More on association lists (and other key-value collections)
Marc Nieper-Wißkirchen
(10 Jun 2020 10:42 UTC)
|
Re: More on association lists (and other key-value collections)
Arne Babenhauserheide
(11 Jun 2020 00:41 UTC)
|
Re: More on association lists (and other key-value collections)
Marc Nieper-Wißkirchen
(11 Jun 2020 10:07 UTC)
|
Re: Usecase: chaining operations after "optionals"
Arne Babenhauserheide
(10 Jun 2020 10:28 UTC)
|
Re: Usecase: chaining operations after "optionals"
Marc Nieper-Wißkirchen
(10 Jun 2020 10:32 UTC)
|
> > Using two-element lists instead of pairs means that another pair > > has to be needlessly allocated for each entry in the association list. > > We have already alists and plists. Maybe, it makes sense to coin another > term, say, xlists where the entries are proper lists Interesting idea. Plists have a different structure from alists (though they support equivalent operations and take the same number of pairs for storage). Xlists however are a special case of alist where the cdr of each association pair happens to be a list. Hence it may be possible to fold xlist operations naturally into the alist API without having to talk about a new kind of list. It would also be possible to have `xplists` :) If you store a list as the value of each plist entry. You can also store a list as the value of each hash-table entry, which I have done countless times. It's very useful. I presume SRFI 146 mappings could have lists as values. Hence I'd suggest starting from the fact that any key->value collection (John would call them dictionaries) can have lists for values. Alists (and plists) can have duplicate keys. That raises the additional concern of what to do about duplicate keys whose values are lists. Should we only take the list corresponding to the first key, or should we `append` the lists from all entries with that key? > While alists will be more efficient for simple key-value pairings, > xlists will have advantage that they allow multiple values to be stored > for a key: Indeed. Another advantage is that consing dots are really not readable to people who are not Lisp diehards. Even I don't like them asthetically and find them inconvenient when editing :) Xlists are something a Python or JavaScript programmer for example can comprehend immediately, since they look just like Python lists, just with parentheses instead of square brackets or curly braces. This is especially important when using S-expressions for data files which are meant to be comprehensible to Lisp casuals or people from other language communities.