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 03 Sep 2022 18:18 UTC

Am Sa., 3. Sept. 2022 um 19:21 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
>
>
> On Sat, Sep 3, 2022 at 12:45 PM Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:
>>
>> Am Sa., 3. Sept. 2022 um 15:51 Uhr schrieb Wolfgang Corcoran-Mathe
>> <xxxxxx@sigwinch.xyz>:
>
>
>>
>> > 9. Major suggestion: Would it be reasonable for all of the
>> > syntax-like procedures to accept thunks *or* promises?  I believe
>> > this could be very useful, although the names might need tweaking.
>> >
>> > Delayed evaluation always gets short shrift in Scheme.  It would
>> > be a sad statement of the current situation for something called
>> > "lazy-and-procedure" to have nothing to do with delayed evaluation.
>
>
> Thunks are a form of delayed evaluation that do
>  not memoize, unlike promises.
>>
>> Promises do not form a disjoint type. Runtime-dispatch won't be
>> possible. Or what do you have in mind?
>
>
> That's all right, as long as you test 'promise?' before 'procedure?', thus:
>
> (cond ((promise? thunk)
>            (force thunk))
>           ((procedure? thunk)
>            (thunk))
>           (t (error "not a thunk")))
>
> or more simply:
>
> ((promise? thunk) (force thunk) (thunk))

That would work if all procedures returned by "lambda" and by all
other procedure constructors but "force" and "make-promise" and using
only the standard exports of R7RS to construct them are guaranteed to
be disjoint from possible values on which "promise?" returns true. I
may be wrong but I currently don't see where R7RS makes this
guarantee.