[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] Post-plebiscite issue #3: structure-sharing for mapping
- To: will@x
- Subject: Re: [Scheme-reports] Post-plebiscite issue #3: structure-sharing for mapping
- From: John Cowan <cowan@x>
- Date: Sun, 12 May 2013 15:29:14 -0400
- Cc: scheme-reports <scheme-reports@x>
- In-reply-to: <3704139.1945361368375566205.JavaMail.root@zimbra>
- References: <10011870.1945341368375388520.JavaMail.root@zimbra> <3704139.1945361368375566205.JavaMail.root@zimbra>
> (I'm posting as a random member of the Scheme community who knows some
> of the relevant history and engineering tradeoffs associated with this
Thanks for weighing in.
> You need to be careful here, lest you write a specification that requires
> (eq? '() (map values '()))
> to return false.
There has never been any question of *requiring* `map` and friends to do
structure-sharing, only of whether it should be explicitly permitted or
merely (as is now the case) implicitly permitted. It's an optimization
that would require very special circumstances to permit, since a compiler
is unlikely to notice in advance that a non-trivial procedure is actually
implementing the identity function. Run-time detection is also expensive;
to my mind, it would make sense only when space is tight and memory
access performance is no issue at all.
On the opposite side of the issue, the editorial team has added language
to the storage model (section 3.4) clarifying that "newly allocated" objects
that have no locations may not, and in the case of the empty list, must not,
actually be newly allocated.
> Note also that (eq? '#() (vector-map values '#())) returns false in some
> current implementations, but returns true in others. R7RS should continue
> to allow that behavior. (All conforming implementations return true when
> the eq? is changed to eqv?, but some implementations achieve that using a
> Singleton pattern while others achieve it by making eqv? more complicated.)
In fact, `eqv?` in both R7RS and R5RS is permitted to return either
#t or #f to (eqv? "" "") and (eqv? '#() '#()), as the examples show.
It's permitted and reasonable, but not actually a standards requirement,
to make `eq?` distinguish such objects and `eqv?` identify them.
> In my opinion, the R5RS, R6RS, and R7RS draft 9 all err when they say eq? is
> an equivalence predicate without alluding to the restricted domain of values
> for which it is an equivalence predicate.
I don't understand the force of this remark. After all, neither `eq?` nor
`eqv?` do what you expect on arbitrary procedures, and both of them are
total, always return a boolean, symmetric, transitive, and respect the
indiscernibility of identicals (if not always the identity of indiscernibles).
What definition of "equivalence predicate" are you using that applies to
`eqv?` but not to `eq?` as specified in R5RS?
> IMO, the R6RS also erred by requiring eq? and eqv? to behave exactly the same
> on procedure arguments. That rules out implementations in which
> (let ((p (lambda (x) x)))
> (eqv? p p))
> is always true but not always true when eq? is substituted for eqv?.
The WG is still discussing this issue (#467).
No saves, Antonio, loke es morirse en su lingua. Es komo John Cowan
kedarse soliko en el silensyo kada dya ke Dyo da, komo cowan@x
ser sikileoso sin saver porke. http://www.ccil.org/~cowan
--Marcel Cohen, 1985
Scheme-reports mailing list