William D Clinger <will_at_ccs.neu.edu> writes:
> (map proc list1 list2 ...) procedure
>
> Proc should be a procedure that takes as many arguments as
> there are lists, the lists should all have the same length,
> and proc should not mutate any of the lists.
As the behavior of `map' is essentially unspecified if these
conditions are not met, it's unclear to me how this fits the "should"
requirement level, which says "that the implications must be
understood and weighed before choosing a different course": As there's
no information in the draft about the implications, it's hard to
understand them. Arguably, a specific Scheme system might provide
more information or extensions that allow gauging the implications,
but I'm unsure whether this hypothetical possibility should in fact
influence the wording in the report itself.
What instead should happen, IMHO, is, in cases like this, that the
mustard in the introduction specifies only the responsibilities of the
programmer (which continue to be "must"-level responsibilities), and
that the responsibilities of the implementation are different.
This was actually my intention with the 5.92 draft, but I
inadvertently omitted some crucial wording in the "terminology"
chapter that describes it, and made some further errors down the road.
--
Cheers =8-} Mike
Friede, V?lkerverst?ndigung und ?berhaupt blabla
Received on Sun Feb 25 2007 - 03:57:07 UTC