Re: SRFI 282: Missing R7RS (Type) Predicates Artyom Bologov 16 Sep 2026 10:39 UTC

Hi Marc,

> - R7RS does not have a notion of a library objects so the procedure
> `library?` can have no meaningful use in portable code.

I agree that R7RS has no notion of a library as an object /
type. However, some implementations (like STklos) do represent libraries
as modules. Tangible and programmatically manipulable objects.

> Moreover, in
> implementations having the notion of a library object, it may return
> #t on completely incompatible objects.

Not sure I understand this passage. The SRFI says “returns true whenever
given a library object, and false otherwise,” so it’s clear that it only
returns #t for actual library objects.

Seeing your comment on alist environments below, I realize that
libraries can be alists too. But checking whether alist is actually a
library alist (by tracking locations, maybe) is on the
implementation. Returning #f is always an option when in a bind.

> - Environment specifiers need not be a distinct type in R7RS (they
> could be an alist, a hashtable, a vector, an import spec, etc.). So
> the lack of `environment?` from the standard is not an "interesting"
> omission but correct.

I disagree. If there’s a notion of environment—there should be a
type / predicate. Chibi has the respective type / predicate, thus the
need for unification. #f can be returned when in doubt.

> - I don't get the "need" for `parameter?`.  What is this supposed to
> mean when parameters can be procedures?

Yes, they can. But they might as well not be. Thus the need for the
predicate.

> - In many macro systems, a syntax transformer is just a procedure
> (taking a syntax object and returning one). It is unclear how a useful
> `syntax-transformer?` could be defined. Moreover, in R7RS,
> `syntax-rules` is not a keyword introducing an expression form so
> syntax transformers are not first-class objects.

syntax-transformer? can be defined as ##sys#macro? on Chicken or as
location-tracking code on other implementations, like I noted above.

So, to summarize: I realize that some implementations might not
represent these types as necessarily distinct. But, on those that do
represent them, these predicates are genuinely useful for, e.g.,
type-based introspection à la SRFI 279.

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