On Wed, Sep 16, 2026 at 02:39:59PM +0400, Artyom Bologov wrote:
> Hi Marc,

Hi Marc, Artyom,

In general, I agree with Marc.  These all deliberately have no
predicate, and IMO trying to standardize a predicate for them seems
counterproductive, *especially* in cases where an implementation is
unable to even make the distinction.  Hypothetical code relying on
this SRFI would also need to be able to rely on the discriminatory
power of the predicates.

The trivial definitions which just return #f for every object just
make things more confusing, IMO.  AFAIK there is no other first-class
type in the standard for which its corresponding predicate may return #f.

> > - 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.

You can't even reify a library in standard code, so IMO that's a
moot point.  It makes more sense to standardize this predicate in
a SRFI which makes modules/libraries first-class, instead of trying
to define it here, just in case, because some implementations happen to
have first-class modules.

> > 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.

FWIW, I don't understand this point either.

> 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.

See my earlier comments about code relying on discriminatory power and
trivial definitions.

> > - 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.

For environments, I would agree a predicate would be useful, as the
standard already has procedures which return such objects.  OTOH, it
would also sort of require environments to be distinct objects,
otherwise it would be impossible to tell apart a cons cell from an
"environment" without traversing the entire list.

> > - 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.

If you do this, I'd suggest also adding a continuation? predicate for
the procedure-like objects that call/cc passes to its argument.

I'd like to note that this is a *different* "continuation?" predicate
than the one CHICKEN implements in (chicken continuation).
https://wiki.call-cc.org/man/6/Module%20(chicken%20continuation)#continuation

This may lead to even more confusion.

Also, it is somewhat onerous for implementations to require being able
to discriminate procedures of different "subtypes", as that would
require somehow tagging them with the subtype.

> > - 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.

How does one obtain such a transformer in standard code, though?
I think for this SRFI it makes more sense to look at what the standard
allows or makes possible and leave standardization of predicates to
other SRFIs that define such entities to be first-class.

Cheers,
Peter