Re: Position of 'proc' argument in for-each etc. taylanbayirli@xxxxxx 13 Sep 2015 11:46 UTC

John Cowan <> 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!