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