On 2026-04-03 19:29, John Cowan wrote:

> Another problem with "is" is that it isn't a noun phrase, which is
> appropriate for creating an object. "Make-assertion" would make sense
> to me.

That's very true.  Very explicit, descriptive and on point.

You are right, is is actually creates and object and sends it to
test-runner, not doing assertion itself.  The same thing for test and
suite, they are not testing or grouping items themselves, they only
create thunks and send them to test runner and test-runner may or may
not do grouping, running or whatever.

However, we can't communicate this semantics via the code without
blowing up the screen with text.

(suite::enclouse-body-into-thunk-and-send-to-test-runner-for-loading
  (test::enclose-body-into-thunk-and-send-to-test-runner-for-loading-not-running-yet
    (is::create-an-asserting-thunk-from-the-predicate-and-send-to-the-test-runner-for-execution-during-test-run
      (equal? (= 2 (+ 1 1))))))

This is very descriptive and correct, but unpractical if we treat code
as a plain text and operate on it from usual text editor.  That's why I
suggest to keep the naming as compact as possible. May be in cost of it
being slightly more obscure in favour of future readability.

Learning and understanding the semantics will take time (as it does for
many Scheme subsystems and libraries).

(make-person
  (name "Andrew")
  (occupation "SRFI writer"))

it's not clear what will happen here. Are name and occupation field
constructors or independed functions?

Is this a usual function call (name "Andrew") and it produces some kind
of a name object as the first positional argument to (make-person) call
or it's a record intialization and we can get the same result with code
like this:

(make-person
  (occupation "SRFI writer")
  (name "Andrew"))

Same way, after a brief reading of testing library documentation,
examples and/or spec, people will quickly learn the semantics and will
start reading code easily and understand how tests will be executed.

I would appreaciate any suggestions on how to improve the spec to make
the semantics clearer.

--
Best regards,
Andrew Tropin