Sam TH <samth_at_ccs.neu.edu> writes:
>> That someone wants to write sloppy logging code is not a sufficient
>> excuse for disallowing returning any number of values by the argument
>> of for-each.
>
> It's written correctly, it just doesn't accept all the possible
> arguments that `for-each' does.
It should if it's meant to be a replacement of for-each, and it's
trivial to fix it to accept all those arguments: replace let with
let-values.
> You're suggesting that any time a function is used as an argument,
> the code is incorrect if it doesn't expect that function to
> potentially return multiple values.
Not at all. Only for those functions which are evaluated for their
effect, with their result(s) ignored.
> Alternatively, that higher-order functions should not be used with
> side-effecting procedures as their arguments.
Again, nobody is proposing that.
It has been proposed that a higher order function which assumes that
its argument will return a value needs not to be compatible with an
argument which does not return a value.
The converse is still true: when a value is not expected but is
provided, the code works (and the value gets ignored).
> You seem to think the function I wrote should either be significantly
> more complex,
Replacing "let" with "let-values" is not significantly more complex.
> or that certain standard procedures should be specified so that they
> don't work with my function.
This already the case: your function doesn't work with the "values"
function.
> What advantage is being gained here?
For example a bug when someone confuses "map" with "for-each" is
caught early. When "map" is used instead of "for-each", it fails when
its argument doesn't return a value. When "for-each" is used instead
of "map", its context fails because "for-each" itself doesn't return
a value.
--
__("< Marcin Kowalczyk
\__/ qrczak_at_knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Received on Mon Oct 02 2006 - 15:00:44 UTC