Proposed solution to the "predetermined states" problem Wolfgang Corcoran-Mathe (22 May 2026 23:18 UTC)
Re: Proposed solution to the "predetermined states" problem Wolfgang Corcoran-Mathe (22 May 2026 23:26 UTC)
Re: Proposed solution to the "predetermined states" problem Peter McGoron (23 May 2026 00:02 UTC)
Re: Proposed solution to the "predetermined states" problem Peter McGoron (23 May 2026 01:18 UTC)
Re: Proposed solution to the "predetermined states" problem Peter McGoron (23 May 2026 13:44 UTC)
Re: Proposed solution to the "predetermined states" problem Wolfgang Corcoran-Mathe (23 May 2026 15:15 UTC)
Re: Proposed solution to the "predetermined states" problem Wolfgang Corcoran-Mathe (23 May 2026 16:28 UTC)
Re: Proposed solution to the "predetermined states" problem Peter McGoron (23 May 2026 17:00 UTC)
Re: Proposed solution to the "predetermined states" problem Peter McGoron (23 May 2026 17:02 UTC)
Re: Proposed solution to the "predetermined states" problem Wolfgang Corcoran-Mathe (24 May 2026 17:15 UTC)
Re: Proposed solution to the "predetermined states" problem Peter McGoron (03 Jun 2026 15:05 UTC)
Re: Proposed solution to the "predetermined states" problem Wolfgang Corcoran-Mathe (03 Jun 2026 15:42 UTC)
Re: Proposed solution to the "predetermined states" problem Wolfgang Corcoran-Mathe (03 Jun 2026 16:11 UTC)
Re: Proposed solution to the "predetermined states" problem Peter McGoron (03 Jun 2026 16:15 UTC)
Re: Proposed solution to the "predetermined states" problem Wolfgang Corcoran-Mathe (03 Jun 2026 19:51 UTC)

Re: Proposed solution to the "predetermined states" problem Wolfgang Corcoran-Mathe 03 Jun 2026 15:42 UTC

On 2026-06-03 11:04 -0400, Peter McGoron wrote:
> On 5/24/26 13:14, Wolfgang Corcoran-Mathe wrote:
> > Unfortunately, the SRFI's claim that a portable implementation is
> > impossible remains true: most of SRFI 271 be implemented with
> > 'make-custom-binary-input-port', but not the 'random-port-state'
> > accessor.  So close!
>
> Wouldn't this be implementable with a custom `get-position` in
> `make-custom-binary-input-port`? Then `random-port-state` is just
> `port-position`. (In a sense, a state *is* the position of the port,
> it's just not an integer. R6RS explicitly supports such a scenario.)

I don't think it does.  The return value of 'port-position' is allowed
to be implementation-dependent only for textual input ports.  For binary
input ports, the position is an exact integer.  Chez and Guile both
enforce this type requirement.

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