Position of 'proc' argument in for-each etc.
taylanbayirli@xxxxxx
(12 Sep 2015 21:00 UTC)
|
Re: Position of 'proc' argument in for-each etc.
John Cowan
(12 Sep 2015 22:08 UTC)
|
Re: Position of 'proc' argument in for-each etc. taylanbayirli@xxxxxx (12 Sep 2015 23:32 UTC)
|
Re: Position of 'proc' argument in for-each etc.
John Cowan
(13 Sep 2015 01:06 UTC)
|
Re: Position of 'proc' argument in for-each etc.
taylanbayirli@xxxxxx
(13 Sep 2015 11:46 UTC)
|
Re: Position of 'proc' argument in for-each etc.
Per Bothner
(13 Sep 2015 14:31 UTC)
|
Re: Position of 'proc' argument in for-each etc.
taylanbayirli@xxxxxx
(13 Sep 2015 14:40 UTC)
|
Re: Position of 'proc' argument in for-each etc.
John Cowan
(13 Sep 2015 17:39 UTC)
|
Re: Position of 'proc' argument in for-each etc. taylanbayirli@xxxxxx 12 Sep 2015 23:32 UTC
John Cowan <xxxxxx@mercury.ccil.org> writes: > Taylan Ulrich Bayırlı/Kammer scripsit: > >> (Do note the over-arching theme of SRFI-125 trying to imitate SRFI-1 >> with awkward results, or the even wider over-arching theme of forcing >> consistency where it doesn't necessarily make sense, like adding >> make-list, list-set!, etc. to R7RS-small...) > > R4RS, R5RS, R6RS, R7RS-small, SRFI-1, SRFI-13, SRFI-43, SRFI-113, etc. > etc. Consistency makes learning a lot easier. All of those define procedures that accept multiple collections as rest arguments, except guess which SRFI. ;-) That being said, CL, Elisp, Guile, and probably most others which define some -for-each, -map, and -fold operations on hash tables oblige with the typical ordering as well. CL and Elisp aren't exactly to be admired in design decisions though. Guile's might have been a historic accident too, simply imitating others. I'll note that Racket has 'proc' appear last in 'hash-for-each'. And Racket is a Scheme that cares a lot about clean design as far as I know. The same goes for Gauche, though there the 'knil' for the -fold appears after the 'kons'... Taylan