Email list hosting service & mailing list manager

Eq? issue Andre van Tonder (04 Jan 2006 07:44 UTC)
Re: Eq? issue Michael Sperber (05 Jan 2006 18:47 UTC)
(missing)
Re: Eq? issue Michael Sperber (08 Jan 2006 14:28 UTC)
Re: Eq? issue Marcin 'Qrczak' Kowalczyk (08 Jan 2006 20:08 UTC)

Re: Eq? issue Michael Sperber 05 Jan 2006 18:46 UTC

Andre van Tonder <xxxxxx@now.het.brown.edu> writes:

> I have a few questions regarding the eq?-issue:
>
> - Can one construct/traverse an eq?-cyclic or eqv?-cyclic graph of
>   immutable record nodes?
>
>   According to the spec, it seems that an eq? cyclic graph of
>   immutable nodes cannot be constructed,

Correct.

>   so it would have to be eqv?-cyclic, but the spec does not
>   guarantee that
>
>    (let ((f (lambda () (construct ...))))
>      (eqv? (f) (f))) => #f
>
>   for /immutable/ records, which I think would be required for
>   such cyclic graphs.

I'm not sure what exactly you mean here---do you mean that
EQV?-*distinctness* would be required to traverse the graph in finite
time?

> - I would not like to artificially declare an immutable record as
>   mutable just so I can use it in a cyclic graph.

That's a very good point (one that Richard Kelsey had also reminded me
of earlier).  The problem is, of course, that mutability happens at
the type level rather than the object level.  (A general problem with
this class of record systems---too much stuff happens at the type
level.)

If you look in the reference implementation, you'll see that the lower
layer on top of which records are constructed ("vector types") doesn't
have this problem---it associates mutability with objects, and allows
an object to be made immutable after creation.

> - A problem with treating mutable and immutable differently is that
>   mutable might easily become immutable in the process of development
>   if a field is dropped or changed - suddenly a program may break in
>   places that are difficut to debug.

> - Another problem is that programs that use eq?/eqv? incorrectly will
>   mostly work on some Schemes, only to fail, and then mysteriously
>   depending on compiler switches and type inference controlling unboxing,
>   on others.

Yes; we debated that for quite a while.  (Of course, there's an issue
bullet on it.)  What we're doing is mainly following the tradition of
R5RS, which allows the same kind of unboxing.

That unboxing should be supported at *some* level language seems quite
clear to me, as this enables setting up certain kinds of abstraction
barriers.  That it should happen at the level of records is less clear
to me, but we don't have any other place currently.

--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla