by default; a new optional argument restores the old behavior
(but the default behavior is consistent with the old docs and with
the vast majority of existing uses)
The implementation is ugly for performance reasons. A new primitive
`prop:arity-incomplete' property determines when to return #f for
`procedure-arity-includes?' in default mode. A nicer implementation
would be to redefine `procedure-arity-includes?' at the kw-proc level,
but the bytecode optimizer's and JIT's treatment of the built-in
`procedure-arity-includes?' is important. The implementation choice
could be revisited after cross-module inlining is implemented.
Closes PR 11978
the first function's arity is 1, avoiding another `call-with-values'.
The difference in timing is in the noise (looks like `call-with-values'
is optimized for an arity-1 receiver), but it seems more in line with
the rest... Incidentally, it steps around the problem in PR11981.
The new version fixes some problems with the previous one, most notably
it can create a keyworded function when the last input is is keyworded.
`compose1' is a restricted variant that requires single values in the
composed pipeline -- besides being potentially faster (probably more
if/when there is cross module inlining), it has a semantical
justification, similar to the restricting function call arguments to
return single values, with similar robustness benefits. The
implementation of both is done in a generalized way, and the results can
be faster for both `compose' and `compose1'. (Not by much -- 20% and
30% resp.)
One thing that it could do is to reduce the resulting arity to match the
last given function. I didn't do this since it adds a significant
overhead to the result. (No strong opinion on doing that...)
The problem is that it spits out a warning message on stderr whenever it
can't find a git repository to extract release announcements (from
annotated tags). Resolving this will require some way to (a) tell drdr
to ignore such output, (b) make it run the code with a $GIT_DIR
environment variable set to the git tree, or (c) make it set some
environment variable so the web build will avoid such messages. (I
prefer the first most, and the last least.)