Re: circular <= shared

[bear <bear@xxxxxxxxx>]

On Tue, 17 Dec 2002, Matthias Radestock wrote:

>The SRFI fails to distinguish between sharing and circularities. This is
>important because R5RS *does* specify how non-circular shared structures
>should be written/displayed(*). For instance
>  (define x (cons #f #f))
>  (define y (cons 1 1))
>  (set-car! x y)
>  (set-cdr! x y)
>  (write x)
>should produce
>  ((1 . 1) 1 . 1)
>when written in an R5RS-conformant system, and *not*
>  (#0=(1 . 1) . #0#)

You may be correct about the implementation of (write), but
part of the point of (write-showing-shared) is that sharing,
including but not limited to circularity, ought to be detected
and written in a form that's recoverable.

>iirc, Al Petrofsky posted an algorithm that detects circularities
>without also catching sharing. It has higher computational complexity
>and is harder to implement than detecting all sharing.

Numbers are not interesting (in the sense of the (interesting?)
subfunction in the reference implementation), because they may
have an (eq?) relationship whenever they are (eqv?).

However, (eq?) relationships on strings, etc. even if they don't
involve circularities in cons-cell structure, should be preserved
by the output.  Since the objective of the SRFI is capturing eq?
relationships (including but not limited to circularities) as
structures are output, I will have to go to the implementation
and look at the (Interesting?) function to make sure they do get
caught.

>(*) Arguably, R5RS even specifies how circular structures should be
>written - as infinite outputs.

That is a behavior that's somewhat hard to implement and cope
with; at some point you'd be getting back a "string" which is
really a port, with an attached output-generating function so
that you could read it forever on a lazy basis.  It would
require low-level twiddles and hacks deep into the guts of
implementations, and I think I'd rather avoid writing a
coherent document for it right now.

				Bear