Arne,

> Could an implementer start with
>
> (define procedure-type-of procedure-check-of)
> (define type->check identity)
>
> and then incrementally adjust the return values of procedure-type-of,
> keeping a map from these values to predicates in type->check ?
>
> That would reduce the required implementation work while opening the
> possibility for implementations to provide more detailed information.

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.)

>>> The core question for me is here: what do people need as portable
>>> procedure? Is type-of intended to trigger an implementation specific
>>> output or is it intended to be a building block for portable tools?
>>
>> For type-of in particular, the goal is to have at least the name and
>> return format to converge across implementations.
>
> It’s definitely a step yes.
>
> 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.

Now that I think of it, maybe procedure-check-of should allow dotted
argument list after all…

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