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)
|
John Cowan <xxxxxx@mercury.ccil.org> writes: > Taylan Ulrich Bayırlı/Kammer scripsit: > >> 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. > > If you want Ruby (which likes lambda arguments to be last for syntactic > reasons) you know where to find it. I want to make Scheme more readable, not imitate some other language. >> 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. > > Racket is an implementation that cares a lot about Racket, as I've said > before. I don't think this counts towards Racket's general deviance from Scheme. SRFI-69 calls for-each "walk" to be able to put the proc last without controversy. Gauche uses the proc-last order. I just noticed that MIT/GNU Scheme also uses the proc-last order. And Bigloo too. Chicken, Kawa, and Chibi have no native hash table API. R6RS has no operation like for-each on hashtables. Gambit, Larceny, and Guile use the proc-first order. I don't know if I missed any "significant" Scheme implementations. (Apologies about favoritism, as always.) So for the ones other than -fold, it definitely seems to be an acceptable idea at least. But it's also all partly moot now, because after all I decided to call the operation -walk too. Not only because of the different argument order, but also because the order of applications to the entries is unspecified, which is a perhaps much more pernicious deviance from typical for-each semantics. To solve the -fold issue as well, I decided to do some more renaming of the procedures. I'll mention this in a new thread on the SRFI-126 ML. And a fun-fact: Bigloo's hashtable-filter! is documented as "filtering *out*" elements (emphasis mine) and doesn't disambiguate on whether it works like your typical filter! or like remove!. Naming things really is one of the hardest problems in computing! Taylan