Wolfgang,

> As with any other kind of communication, a SRFI is more likely to be
> read if it addresses issues other people have encountered.  It really
> would help the SRFI’s chances of adoption if it suggested some reason,
> other than theoretical completeness, to bother with it.

That does make sense. This SRFI ties in with SRFI 279 (as you noted) and
scheme-index in that it fills in the gap in predicates for entities that
do exist in both of these. So there are at least two use-cases, albeit
quite meta still.

> Presenting some useful operations on these types would go a
> long way toward making them seem worth adopting.  These would help
> answer the questions some readers will have, e.g. “when would I care
> whether a random procedure is actually a parameter object?”  Your
> In(tro)spection Protocol SRFI includes some environment operations
> which seem (?) to be nullary; they could be updated and presented
> here as operations on environment objects.

Yes, this is one way to do it. However, I think that SRFI 279 properties
belong to SRFI 279 and not here. While defining predicates for things
without operations / introspection on them is somewhat unintuitive, it
also deserves space. And there’s a precedent for that too—see, well,
bytevectors in R7RS, not even having a bytevector->list procedure.

I’d also like to leave environment operations out of this SRFI because
they need much more careful design and consolidation than adding
predicates. So I’d prefer adding at least the vital part (predicates)
and leaving a more involved part (operations) for later. I might even be
too incompetent to do a proper environments SRFI, but I believe in
myself pulling off standardizing a bunch of predicates.

> Of course, a sample implementation or an idea of how to implement these
> types would also help.

This is way beyond my competence and it does change the SRFI scope
significantly. I want to leave description / specification of
environments and parameters to R7RS and other specialized venues and not
duplicate the unnecessary work (that I’m likely to do poorly) in a shim
SRFI like 282.

So, to summarize: predicates are necessary for other projects that I
personally am really invested in. While operations relating to these
types are painfully beyond my competence and the scope of my work.

Is that a sane response?

Thanks,
--
Artyom Bologov
https://aartaka.me