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. John Cowan 12 Sep 2015 22:08 UTC
Taylan Ulrich Bayırlı/Kammer scripsit: > SRFI-69 avoids the issue by calling it "walk" instead of "for-each." > Can't we just break from the convention here and do what makes sense? SRFI-125 supports both -for-each with the standard order and -walk with the SRFI-69 order. > Hash-table-fold would take 'hashtable, init, proc' like SRFI-125 supports both orders. > (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. -- John Cowan http://www.ccil.org/~cowan xxxxxx@ccil.org You are a child of the universe no less than the trees and all other acyclic graphs; you have a right to be here. --DeXiderata by Sean McGrath