Removing SRFI 170 from the CC list.

> From: Lassi Kortela <xxxxxx@lassi.io>
> Date: Friday, August 14, 2020 10:12 AM
>
> [ Ignored in favor of getting to the heart of the matter. ]
>
> SRFI 198 is meant to let people represent absolutely any statuses of any
> kind. The spectrum is so wide that we'd be hard pressed to anticipate
> everything. That's why I'm advocating for 198 to be in spirit a simple
> dictionary with a tag attached to it. An empty dictionary being valid as
> usual.

I ask how does it significantly damage *your* vision for SRFI 198 to
add a mandatory "'set" key (we all agree it needs a different name)?

I'd even add a 3rd generic status of something like 'whatever to
'status and 'error for someone who doesn't want to pick either of
those, although a status that's a possible error can be safely given
the 'status value.  In fact, make it a rule of thumb, if you don't
know what set to put it in. don't want to spend any time thinking
about this, use 'status.

There's a whole bunch of useful things the rest of us can do if we can
depend on their being a 'set key with a non-#f value.

Whereas what principle makes it so important that a SRFI 198 object be
a pure dictionary to the point that it can be completely empty???

> [ Irrelevant SRFI 170 examples, except in how I think they show even
>   you realize at some level the need for 'set, if I understand
>   John's followup correctly. ]
>
> [...]

Now John a bit of a distance in that subthread:

> [(foreign-status-key 'set obj) ] will return #f, that's not the
> issue.  The issue is that if it does return #f, we have to use ad
> hoc methods to figure out which specialized handler to dispatch to.
> If it never returns #f, we can systematically dispatch on all the
> cases the main handler knows about.

> I note that in all your sample plists you specify the 'set key.  Why
> then are you so allergic to simply requiring it to be present (that
> is, not #f)?  It's an incredibly minimal requirement, like saying
> your name when you call someone (or relying on caller-id to "say" it
> for you), and in no way constrains the use of the API.

I'll repeat his question with emphasis.  Why are you so allergic to
this concept of a single required key, to the point you've completely
derailed SRFI 198?

- Harold