[r6rs-discuss] [Formal] proc in hash-table-update! should not mutate hash-table

From: William D Clinger <will>
Date: Sat Feb 24 19:44:31 2007

I am posting this as an individual member of the Scheme
community. I am not speaking for the R6RS editors, and
this message should not be confused with the editors'
eventual formal response.

Sam TH wrote:

> This imposes a complex relationship between the order in which proc is
> called in the various arguments, and the order in which arguments to
> the cons and apply functions are evaluated.

My proposed specification would imply that every call to
cons whose result appears in the result to map must be
performed after all calls to proc have returned. As Sam
points out, this is probably too strong; it should be
weakened by changing the specification to say "When all
arguments are as they should be, and all calls to proc
return, the map procedure must return a list that is
equivalent (in the sense of equal?) to one of the lists
that might be returned by the following definition of
map."

BTW, a client of the map procedure cannot distinguish the
calls to apply from calls to proc that do not go through
apply.

> For example, if the
> Scheme implementation in which map was used was one where every
> procedure application evaluated the arguments from right to left, then
> this implementation of map would do the same with regard to the order
> in which proc was called.

Irrelevant. The proposed specification does not say that
map must behave as though it were defined that way in some
particular implementation, merely that map must behave as
though it were defined that way in the Scheme language.
In particular, R6RS-conforming implementation A is allowed
to implement map in R6RS-conforming implementation B,
which may not share implementation A's peculiarities.

> Your language
> requires this order to be the same as that in which proc is actually
> called, even if map is implemented in some other way.

Untrue, for the reason given above.

> This accidental (I assume) overspecification points to the problem of
> specifying the behavior via a sample implementation - the sample
> implementation often overdetermines the result.

Agreed. In this case, however, there has been a long
history of buggy implementations, which can be blamed
on the older specifications' reliance on the general
rule that procedures have no observable effects apart
from the ones mentioned or implied by their informal
specification. Far too many implementors have failed
to comprehend that their buggy definitions of map have
observable effects that are implicitly forbidden by
the R5RS specification. IMO, it is time to make the
spec more explicit on this point, even at the risk of
some slight overspecification.

Will
Received on Sat Feb 24 2007 - 19:44:26 UTC