Arne,

>> Besides, portable code would only need and have argument checks and
>> return checks in either of scenarios—multiple values, alist, or records.
>
> How do you solve the issue when there are two typed procedures, one
> using define-checked and one using define-typed?
>
> If there is implementation-specific metadata that may or may not be
> present in the records, they may need different record types.
>
> This could be resolved stating that metadata fields must always accept
> #f as value (as in: cannot retrieve) and then implementation for
> SRFI-253 and SRFI-284 procedures would always use the same record types.

Yeah, that’s my idea here. Have one record type that works with
either. It’s an implementation problem, not an ontological one, I think?

> Besides: SRFI-284 is now the srfi for define-typed (mainly thanks to you).
>
> https://srfi.schemers.org/srfi-284/srfi-284.html

I will definitely review it and leave comments, thanks for working on it!

>> I’m inclined to go down the sequence-of-records route, as it’s the most
>> structured and strict option with clearly named accessors for
>> everything.
>
> What do you mean by "sequence of records"? I thought that the proposal
> was to return one record which has at least two fields (arguments and
> return values).

Peter, in another email thread, have suggested to return a list of
specifications (like you did, but it finally got to me this time) from
procedure-*-of, to support case-lambda et al. So, merging that idea with
records, we get a sequence (list of vector, not sure) of records
specifying checks / types for a procedure.

Does it sound sane?

Best of luck,
--
Artyom Bologov
https://aartaka.me