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:52 UTC
On 2026-06-23 21:42, John Cowan wrote:

> I will point out that mere improbability has been consistently rejected by
> the Scheme community as a reason for accepting a simpler but slightly less
> general solution in place of a more general but more complex solution, e.g.:
>
> 1. The inability of SRFI 231/158 generators to return eof-objects as
> generated elements from lists, vectors, and other general purpose
> collections.
>
> 2. The mess around encoding violations in file contents, file names, and
> system environment variables.
>
> 3. The desire for a literal notation for mixed-precision complex numbers of
> arbitrary widths/formats, a feature provided by exactly zero existing
> Schemes.
>
> All of these complications can, to varying degrees, be eliminated by the
> response "Don't do that, then." But that view has not prevailed.
>
> On Tue, Jun 23, 2026, 4:00 PM Wolfgang Corcoran-Mathe <xxxxxx@sigwinch.xyz>
> wrote:
>
>> Another question about test / suite metadata: Is <metadata-alist>
>> evaluated?
>>
>> For example, would this be valid:
>>
>>   (test ("database round-trip" ctx)
>>     metadata
>>     `((timeout . ,default-test-timeout))
>>     ...)
>>
>> (It seems like it should be.)
>>
>> --
>> Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>
>>

Is it related to evaluation of metadata alist? or mulitple values is?

If about multiple values, I don't see how current `is` limits
generalization.

1. I already mentioned that multiple values can be and, IMHO, should be
destructured before asserting (we keep responsibility unmixed, the
expressive power remains the same).

2. I don't see what assertion of multiple values could mean.  Please
provide any, even hypothetical example if you have.

3. You still can customize assertion logic via test runner configuration
or metadata.

(test ("Default assertion logic" ctx)

  ;=> pass
  (is (values #t #f #t) "multivalue assertion thunk"))

(test ("Custom multi-value assertion" ctx)
  'metadata
  `((runner/assertion-fn . ,values-all-true))

  ;=> failure
  (is (values #t #f #t) "multivalue assertion thunk"))

I still open for discussion, just send a couple examples to show case
the practical usefulness or demonstrate how current implementation
limits the generalization, please.

Genuenly appreciate your enthusiastic help and retrospection in the
other SRFIs history very much!

--
Best regards,
Andrew Tropin