Types and disjointness Shiro Kawai (29 Oct 2022 07:31 UTC)
Re: Types and disjointness Marc Nieper-Wißkirchen (29 Oct 2022 08:25 UTC)
Re: Types and disjointness Shiro Kawai (29 Oct 2022 16:30 UTC)
Re: Types and disjointness Marc Nieper-Wißkirchen (29 Oct 2022 17:29 UTC)
Re: Types and disjointness Shiro Kawai (29 Oct 2022 17:53 UTC)
Re: Types and disjointness Marc Nieper-Wißkirchen (29 Oct 2022 19:32 UTC)
Re: Types and disjointness Shiro Kawai (30 Oct 2022 00:35 UTC)

Re: Types and disjointness Marc Nieper-Wißkirchen 29 Oct 2022 19:32 UTC

I am adding the following paragraph:

        <p><i>Note:</i> This specification does not define the type of
          mark keys conclusively; it only demands that the values
          returned by <code>make-continuation-mark-key</code> are mark
          keys.  This can be exploited by implementations who offer
          specialized procedures for mark keys.  If the implementation
          does not treat any key object in continuation marks
          specially, <code>continuation-mark-key?</code> can
          return <code>#t</code> on all objects.  (Note that in any
          case, any Scheme object can be used as a key object in a
          continuation mark.)</p>

Am Sa., 29. Okt. 2022 um 19:53 Uhr schrieb Shiro Kawai <xxxxxx@gmail.com>:
>
> Ok, I see.
> If that's the case, though, the description of continuation-mark-key? may be elaborated.  I'm not sure the wording but how about something along this line:
>
> Returns #t if obj is a mark key that may be treated specially by the implementation, if make-continuation-mark-key returns an object of such type.  If an implementation does not provide such a type, this procedure may always return #t.
>
>
> On Sat, Oct 29, 2022 at 7:29 AM Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:
>>
>> Am Sa., 29. Okt. 2022 um 18:30 Uhr schrieb Shiro Kawai <xxxxxx@gmail.com>:
>> >
>> > On Fri, Oct 28, 2022 at 10:25 PM Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:
>> >>
>> >> Am Sa., 29. Okt. 2022 um 09:31 Uhr schrieb Shiro Kawai <xxxxxx@gmail.com>:
>> >>
>> >> > - Is prompt-tag argument (call-with-continuation-prompt etc.) required to be an object created by make-continuation-prompt-tag, or can it be arbitrary object?
>> >>
>> >> Yes; see "5.2 Entry format"
>> >
>> >
>> > I should've phrase it this way: Is continuation-prompt-tag? returns #t only for objects created by make-continuation-prompt-tag or default-continuation-prompt-tag ?  But you answered it below (not enforceable).
>> >
>> > Specifically, the question arises in this context: I thought to let make-continuation-mark-key just return a fresh uninterned symbol in Gauche.  It satisfies non-equal?-ness, already has print representation and can reflect given name.
>> > However then, how continuation-mark-key? should behave?
>> >
>> > If we don't have a separate type for the mark keys, and interpret continuation-mark-key? as "returns #t for whatever that can be used for the mark key", then it should always return #t.  If it needs to distinguish whether obj is created with make-continuation-mark-key, we do need a separate type but I don't see why it is necessary.
>>
>> Yes, without further specifications, continuation-mark-key? can always
>> return #t.  For systems, where make-continuation-mark-key returns a
>> special kind of object (e.g. to support a special kind of "fast"
>> marks) and where there are other procedures concerned with such
>> objects, continuation-mark-key? would not be a constant procedure.
>>
>> > I see prompt-tag is different.  Not arbitrary object can be used as a prompt-tag, it is meaningful to have continuation-promt-tag? even if an implementation extends the doamin of objects to be used as a prompt tag.
>> >
>> >
>> >>
>> >>
>> >> > - Is the type of objects created by make-continuation-prompt disjoint from other types?
>> >>
>> >> > - Is the type of objects created by make-continuation-mark-key disjoint from other types?
>> >>
>> >> This is not enforced because it is hard to give it any sense without a
>> >> closed-world assumption.
>> >>
>> >> PS See here for a general attempt to address the problem:
>> >> https://srfi-email.schemers.org/srfi-224/msg/16842716/.