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)
|
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.