Re: Position of 'proc' argument in for-each etc.
taylanbayirli@xxxxxx 13 Sep 2015 11:46 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