Initial comments on 3rd draft John Cowan (04 Jun 2026 05:16 UTC)
Re: Initial comments on 3rd draft Wolfgang Corcoran-Mathe (05 Jun 2026 02:02 UTC)
Re: Initial comments on 3rd draft Peter McGoron (05 Jun 2026 11:47 UTC)
Re: Initial comments on 3rd draft Wolfgang Corcoran-Mathe (05 Jun 2026 22:58 UTC)

Re: Initial comments on 3rd draft Wolfgang Corcoran-Mathe 05 Jun 2026 22:58 UTC

On 2026-06-05 07:46 -0400, Peter McGoron wrote:
> > I realized today that we need to add an equality predicate for
> random-port states, since 'equal?' will not work portably on homogeneous
> numeric vectors, which are the mostly likely types for the purpose.  So
> I will add "(in the sense of random-port-state=?)", instead.
>
> I still don't get why that's necessary, as
>
> 1) extension of equal? to read/write invariant values is a very
> common extension, even if it isn't outright required by the SRFI
> spec,
>
> 2) the representation of a random port state is a choice made by an
> implementer and this SRFI is not portably implementable (yet). The
> implementer would know the acceptable datum/equal? types on their
> implementation.

I see this as a matter of making the specification as clear and as
close to R7RS as possible.  The semantic foundation of every SRFI is
one of the Reports, unless the author says otherwise.  Talking about
random-port states being 'equal?' is nonsense when no Report (or
SRFI, as far as I know) has extended the semantics of that procedure
to all of the types that could be used as states.  It's abject
sloppiness to use implementation-specific semantics for something as
well-known as 'equal?'.

In practical terms, the 'random-port-state=?' predicate might be
useful on implementations (like Chez, at the moment) that do not
extend 'equal?' to homogeneous numeric vectors.

--
Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>