Further issues Wolfgang Corcoran-Mathe (20 Jun 2026 17:55 UTC)
Re: Further issues and New Portable Implementation Andrew Tropin (23 Jun 2026 12:08 UTC)
Re: Further issues and New Portable Implementation Wolfgang Corcoran-Mathe (23 Jun 2026 17:22 UTC)
Re: Further issues and New Portable Implementation Wolfgang Corcoran-Mathe (23 Jun 2026 20:00 UTC)
Re: Further issues and New Portable Implementation John Cowan (24 Jun 2026 01:42 UTC)
Re: Further issues and New Portable Implementation Andrew Tropin (24 Jun 2026 04:52 UTC)
Re: Further issues and New Portable Implementation Andrew Tropin (24 Jun 2026 04:28 UTC)
Re: Further issues and New Portable Implementation Andrew Tropin (24 Jun 2026 04:26 UTC)
Re: Further issues and New Portable Implementation John Cowan (24 Jun 2026 05:30 UTC)
Re: Further issues and New Portable Implementation Andrew Tropin (28 Jun 2026 06:25 UTC)
Re: Further issues and New Portable Implementation John Cowan (28 Jun 2026 10:22 UTC)
Re: Further issues and New Portable Implementation Andrew Tropin (29 Jun 2026 01:37 UTC)
Re: Further issues and New Portable Implementation Wolfgang Corcoran-Mathe (24 Jun 2026 15:56 UTC)
Re: Further issues and New Portable Implementation Andrew Tropin (28 Jun 2026 06:11 UTC)

Re: Further issues and New Portable Implementation Andrew Tropin 24 Jun 2026 04:26 UTC
On 2026-06-23 13:22, Wolfgang Corcoran-Mathe wrote:

> On 2026-06-23 19:07 +0700, Andrew Tropin wrote:
>> On 2026-06-20 13:55, Wolfgang Corcoran-Mathe wrote:
>> > 1. For some reason, 'metadata' appears as a quoted identifer in the
>> > definition of 'test' and its examples.  The form should be:
>> >
>> >     (test (<description> <context-id>) metadata <metadata>
>> >       <body>)
>>
>> originally it was #:metadata, but later Ramin pointed out that it's too
>> guile-specific, we changed it to just 'metadata. Before the previous
>> draft the form was (test <description> 'metadata <metadata> <body>).
>
> I think we may be misunderstanding each other.  At the moment, what
> you've got is equivalent to
>
>     (test (<description> <context>) (quote metadata) <metadata>
>       <body>),
>
> which makes no sense--'quote' isn't doing anything, since this isn't a
> procedure.  The 'metadata' identifier can be detected with syntax-rules
> or syntax-case like any other identifier, e.g.:
>
>     (syntax-rules (metadata)
>       ((test (desc ctx) metadata mlist body ...)
>        ...)
>       ...)
>

Oh, you mean why it's `'metadata` and not just `metadata`?
Like this?

(test ("descr" ctx)
  metadata
  '((hello . there))
  (is #t))

1. It was a transition from #:metadata to 'metadata, both of which are
data in all cases.

2. Yeah, we could go further and remove quoting, but I still prefer
`'metadata` over `metadata` as it makes it clearer that this is a symbol
and this thing won't be evaluated.  It's one extra character to type,
but so explicit to read with no extra cognitive load.

3. I'm not strongly against, but still every time I look at the snippet
above I start thinking: "ctx is the test argument and probably used
somewhere in the test body. Metadata... where it is bound? and where the
value for it comes from? Oh, it's just a syntax tag/marker, not a
variable, okay."

Let me know if you meant something else.

>
>> [Context:]
>>
>> Both test runner and test can modify it.  I'm not sure yet in which case
>> we would like test to change it, but we definitely have power to do so:
>> provide an atomic-box to context and let test set it.
>>
>> [snip]
>>
>> P.S. So to be more precise test has no ability to modify context as it
>> should be immutable, but can touch sideeffectful values from it.
>
> I'm a little confused about what an "immutable" value with
> "sideeffectful values" might be.  If the context is a box, its contents
> be set by one test and read by another, right?  (Not that this is a
> great idea, of course!)

context is a plain alist (and alists are immutable in most Schemes?).
Fixtures are supposed to modify context by creating a new context value
each time and passing further down the stack.

However, some of the alist values can be mutable (e.g. db connection,
socket, atomic-box, etc). I called those values "sideeffectful", not
sure if it's a prefect name though :D  Fixtures and test can access them
and fire side effects against them.  The structure of the context will
remain the same.  It's not enforced by the language or library
implementation, it's more of a convention I guess.  Probably will need
to elaborate on that in SRFI.

Hope, it's clearer now.  Poke me if it still too vague.

>> > 4. "Tests that do not need the context can use _ as the identifier."
>> > I assume this means that 'test' should specifically omit binding the
>> > context value if the context identifer is free-identifier=? to _.  Or
>> > is this just a recommend convention?
>>
>> Yeah, just a recommended convention.
>
> In that case, drop it.  _ has no special meaning, but the current text
> might lead some implementers to explicit un-bind _ in 'test'.

Oki, will rewrite it more explicitly.

--
Best regards,
Andrew Tropin