[r6rs-discuss] [Formal] Requirement to detect circular lists
On Oct 1, 2006, at 5:08 PM, AndrevanTonder wrote:
> Name : Andre van Tonder
> Email : andre at het.brown.edu
> Type : defect
> Priority : minor
> Component : Mutable list arguments
> Version : 5.91
> Pages : 123-125
> Dependencies: None
>
> Summary:
> --------
>
> Requirement of cycle detection in list procedures
> may be too onerous, potential performance problem.
>
> Description:
> ------------
>
> The draft requires procedures such as length, and
> various others, to detect and raise an exception
> if passed a circular list.
> This may adversely affect performance globally
> to accommodate an uncommon bug, in addition
> to complicating the implementation of these
> procedures rather significantly.
1. The claim of "adverse global effects on performance"
needs to be supported. Having used and implemented these
procedures with full error detection under optimizing
compilers, I wouldn't characterize the effects on
performance as "adverse". Additionally, if performance
really matters in this case, you can either add a "fast"
or "unsafe" declaration to your code or implement a
version of these procedures that performs no circularity
detection yourself.
2. The claim of circularity bugs being uncommon may be
true, though there is no evidence of it. I personally
prefer getting an error when I make these bugs since
they are, after all, bugs as you stated.
3. The claim that circularity detection complicates the
implementation of these procedures "significantly" is no
reason for dropping the requirement of raising an
exception. First, the hare-and-tortoise algorithm is by
no means complicated compared to the other tasks that an
implementation must perform. Second, these procedures
are implemented once, correctly, and very rarely need to
be revised. Third and most importantly, even if it were
true that implementing these procedures is complicated,
so what? Making Scheme easy to implement is not a goal
of R6RS as far as I can tell.
Aziz,,,
Received on Mon Oct 02 2006 - 05:11:36 UTC
This archive was generated by hypermail 2.3.0
: Wed Oct 23 2024 - 09:15:00 UTC