Arne,

>>> (define procedure-type-of procedure-check-of)
>>> (define type->check identity)
>
>> Yes, absolutely. procedure-type-of is under-specified exactly because
>> it’s up to implementor to make’n’break it. However, I doubt it will
>> actually be ever implemented this way, because most implementations have
>> types, but not many have built-in SRFI 253-like checks. (The only one I
>> can think of is Chibi, with its predicate-based generic system.)
>
> I might have misunderstood something then.
>
> Aren’t the checks just predicates I can use to verify whether a value
> matches the requirements for the argument?
>
> Something like string? or integer?
>
> What I need for editor-support is a cheap way to answer the question
> “does this value fulfill the requirements of the API?”.

So, the sequence is this:
• Implementations have values
• These values have types
• Most implementations have a way to represent types
• Types represent some checks / restrictions / contracts
• Not many implementations have first-class checks / contracts
• But! checks can be derived from types, e.g. #<type Integer> -> integer?
• That’s the supposed mechanism for procedure-check-of implementation

But procedure-check-of return values are entirely suitable for your
use-case being mere predicates. Even if they are derived from the
original types—doesn’t really matter as long they check things properly,
right?

>>> Do you have plans for representing named (keyword) arguments, optional
>>> arguments and rest arguments?
>>
>> Not really, since they are not part of R7RS. Being that, they are
>> implementation-specific and thus belong to procedure-type-of instead of
>> procedure-check-of. So Guile’s
>>
>> (define* (start-repl #:optional (lang (current-language)) #:key debug)
>>   (start-repl* lang debug prompting-meta-read))
>>
>> Would have
>>
>> (procedure-check-of start-repl)
>> ;; => ()
>> ;; => (integer?)
>> (procedure-type-of start-repl)
>> ;; => (#:optional (lang <language>) #:key (#:debug <boolean>))
>> ;; => (<integer>)
>>
>> Or something. That’s why I have really relaxed requirements for
>> procedure-type-of—it must accommodate.
>
> That sounds like a check whether the arguments in a given form are valid
> could be a way to relax the checking.

Not sure I understand this sentence. Can you rephrase?

> Something like (procedure-types-predicate proc) ⇒ macro that can check
> any kind of values, so the editor can call:
>
> ((procedure-types-predicate start-repl) (current-language) #:debug #t) ⇒ #t

That does sound fun, but I’m not sure if it’s still in scope. And it
feels like the inner workings of this helper would be _really_
implementation-specific. Could that be a library on top of SRFI-283?

>> Now that I think of it, maybe procedure-check-of should allow dotted
>> argument list after all…
>
> I’m not sure.
>
> For define-typed I’m thinking about supporting dotted argument lists with
> something like
>
> (define (all-integer? args) (not (member #f (map integer? args))))
> (define (all-string? args) (not (member #f (map string? args))))
>
> (define-typed (foo a . args) (integer? (all-integer?) -> (all-string?))
>   (apply values (map number->string (cons a args))))
>
> with (all-integer?) being called with the list args as argument to check
> their validity and (all-string?) being called the list of values to
> check their validity.
>
> But that’s not implemented yet and I’m not sure whether it would be easy
> and/or performant.

SRFI-253/273 circumvents this by not allowing checks on rest arguments
at all. But I’ll probably add this returned rest argument check in
SRFI-283 because, if we derive checks from types, there might actually
be types for rest arguments (they are on Chibi, at least.)

Still, this rest check return won’t change the semantics of SRFI-253 et
al. nor the efficiency of SRFI-283 forms.

Thanks,
--
Artyom Bologov
https://aartaka.me