Hi Wolfgang,

Responding to the title: the standard does not specify any procedure or
variable that houses widgets, while environments and parameters (let’s
ignore libraries and syntax for now) do exist as tangible entities,
returned by `environment' and `make-parameter' respectively.

> I respect the audacity of defining predicates for things that either do
> not exist or are not yet detectable.  But I’m not so sure creating types
> by fiat is a good idea.  As others have said, SRFI 282’s predicates
> aren’t really usable in programs, so their only reason to exist seems
> to be theoretical completeness, or to nudge Scheme implementers to
> create more disjoint types (or, in the case of ‘library?’, to create
> a new type out of whole cloth).

That’s why Peter’s suggestion of splitting the SRFI into several
libraries is going to happen in the next draft. Detecting the support
for these types via (cond-expand ((library (srfi 282 environment)) ...))
is a sane approach, I believe.

> As to the predicates themselves, I see two groups.  ‘parameter?’,
> ‘environment?’, and ‘syntax-transformer?’ are straightforward.  I would
> have no complaints if a Scheme implementation decided to distinguish
> these types.  (But the question for *you*, the SRFI author, is why
> should they?)

This is a question of values. I value the match between semantics and
APIs, thus my opinion that these type predicates are “missing.”

> ‘library?’ is something else entirely.  The idea of
> first-class libraries or modules in Scheme is fascinating, but this
> is an absurd way to propose it.  Surely it would be more useful to
> add ‘library?’ to a detailed specification of first-class libraries
> than to drop it here as an alleged missing piece.  As it stands,
> SRFI 282 all but guarantees that the handful of people who adopt
> ‘library?’ will make it an alias for ‘(constantly #f)’.  I strongly
> suggest removing it; it is not only half-baked, but quite raw.

Yes, it will be removed in the next draft, as many others have raised
legitimate concerns about it.

> The point about alleged missing pieces brings me to another suggestion:
> rename the SRFI and rewrite the Rationale.  There is nothing “missing”
> about these predicates with respect to R7RS-small.  Two of SRFI 282’s
> types (libraries and syntax transformers) don’t exist in the Report,
> and there is no indication the editors ever intended to distinguish
> the other two.  You seem to suggest that these were omitted because
> of an oversight.  This inaccurate framing is used to get the SRFI off
> the rationale hook: as long as these predicates are simply “missing”,
> you don’t need to come up with a real reason for creating them.

Indeed, I should probably rewrite the title and rationale. The language
is probably too loose.

> The Rationale’s circular reasoning is evidence of this: you say “the
> predicate set essentially defines what types of objects semantically
> ‘exist’”, then claim that the types you define “otherwise exist in
> Scheme”.

There is no circular reasoning. The reasoning is: predicates restrict /
represent the set of types, but types do exist, and if they lack
predicates, predicates should be added because they must represent the
set of types. That’s why there are scare quotes in the first instance of
“exist”—predicates do not mandate what exists, they only describe it.

> This extension needs to justify its own existence, not
> suggest that it is somehow a patch on the R7RS.

See above.

> I’m sorry for the length of this message, and for falling into a tone
> of invective.  (It’s just a proposal for four Boolean procedures,
> after all!)  I really do like the idea of first-class libraries, and
> would be happy to see a Scheme in which ‘library?’ was a meaningful
> procedure. I can see reasons for some of the other types, as well.
> But I think SRFI 282’s way is simply the wrong way to propose new types.

Might I ask what you suggest as the right way? I was indecisive between
making an SRFI and opening an issue on https://codeberg.org/scheme/r7rs,
but decided to go with an SRFI, because an SRFI is easier / faster to
implement than a standard that’s been like 13 years in the making 😅

I value your message and your righteous anger, and I will address at
least a part of your comments in the next draft. But I still consider
this SRFI worthy of existence and implementation, in some form or
another.

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