SRFI 235 review Wolfgang Corcoran-Mathe (03 Sep 2022 13:51 UTC)
Re: SRFI 235 review Marc Nieper-Wißkirchen (03 Sep 2022 16:45 UTC)
Re: SRFI 235 review John Cowan (03 Sep 2022 17:21 UTC)
Re: SRFI 235 review Marc Nieper-Wißkirchen (03 Sep 2022 18:18 UTC)
Re: SRFI 235 review Wolfgang Corcoran-Mathe (04 Sep 2022 20:06 UTC)
Re: SRFI 235 review Marc Nieper-Wißkirchen (05 Sep 2022 06:31 UTC)
Re: SRFI 235 review John Cowan (05 Sep 2022 16:44 UTC)
Re: SRFI 235 review Marc Nieper-Wißkirchen (05 Sep 2022 17:58 UTC)
Re: SRFI 235 review John Cowan (05 Sep 2022 23:45 UTC)
Re: SRFI 235 review Marc Nieper-Wißkirchen (06 Sep 2022 06:27 UTC)
Re: SRFI 235 review Wolfgang Corcoran-Mathe (06 Sep 2022 19:46 UTC)
Re: SRFI 235 review Marc Nieper-Wißkirchen (06 Sep 2022 21:39 UTC)
Re: SRFI 235 review John Cowan (07 Sep 2022 01:46 UTC)
Re: SRFI 235 review Per Bothner (07 Sep 2022 05:04 UTC)
Re: SRFI 235 review John Cowan (07 Sep 2022 18:37 UTC)
Re: SRFI 235 review Per Bothner (07 Sep 2022 22:23 UTC)
Re: SRFI 235 review John Cowan (07 Sep 2022 23:29 UTC)
Re: SRFI 235 review Marc Nieper-Wißkirchen (09 Sep 2022 09:25 UTC)
Re: SRFI 235 review John Cowan (09 Sep 2022 19:54 UTC)
Re: SRFI 235 review Marc Nieper-Wißkirchen (09 Sep 2022 20:11 UTC)
Re: SRFI 235 review Marc Nieper-Wißkirchen (07 Sep 2022 06:29 UTC)
Re: SRFI 235 review Wolfgang Corcoran-Mathe (07 Sep 2022 18:02 UTC)
Re: SRFI 235 review Marc Nieper-Wißkirchen (07 Sep 2022 20:10 UTC)
Re: SRFI 235 review Lassi Kortela (07 Sep 2022 18:41 UTC)
Re: SRFI 235 review John Cowan (03 Sep 2022 17:17 UTC)
Re: SRFI 235 review Arvydas Silanskas (04 Sep 2022 08:35 UTC)

Re: SRFI 235 review Marc Nieper-Wißkirchen 06 Sep 2022 21:38 UTC

Am Di., 6. Sept. 2022 um 21:46 Uhr schrieb Wolfgang Corcoran-Mathe
<xxxxxx@sigwinch.xyz>:
>
> On 2022-09-05 08:30 +0200, Marc Nieper-Wißkirchen wrote:
> > With just the small language, we can't write sensible ad-hoc polymorphic
> > procedures that handle promises differently.
>
> I agree, although SRFIs can, of course, specify procedures that can’t
> be portably implemented.

Sure. But in this case, it is not the problem that an implementation
would have to be non-portable but that there cannot be an
implementation, portable or not, on every Scheme implementation that
is allowed by R7RS. (As I tried to explain earlier, even access to
something like "%true-promise" would not help.)

In the context of the large language and its foundations, we should
have a discussion on whether we should tighten the specification of
promises in the small language.  At the moment, implementations have a
lot of creative leeways but this does not help portable code.  I would
suggest either making promises a disjoint type or making them
indistinguishable from ordinary values, which would mean implicit
forcing and probably a Haskell-like kernel for Scheme.