Am Sa., 29. Okt. 2022 um 18:30 Uhr schrieb Shiro Kawai <shiro.ka...@gmail.com>: > > On Fri, Oct 28, 2022 at 10:25 PM Marc Nieper-Wißkirchen > <marc.nie...@gmail.com> wrote: >> >> Am Sa., 29. Okt. 2022 um 09:31 Uhr schrieb Shiro Kawai >> <shiro.ka...@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/.
