develooper Front page | perl.perl5.porters | Postings from November 2016

Re: RFC: core sub signature introspection

Thread Previous | Thread Next
November 23, 2016 00:57
Re: RFC: core sub signature introspection
Message ID:
Aaron Crane wrote:
>containing an initial implementation of introspection for core
>subroutine signatures.

Terrible idea.  A signature is a sub's implementation of part of its
behaviour, not public metadata.  The same thing can be implemented in
other ways, and the choice of implementation is, and should remain,
an internal matter for the sub.  A sub should be able to switch between
implementations without callers seeing any change in the API.

It may be reasonable to add metadata fields to subs that correspond to
some of the things you're picking out from the signature.  If so, they
should be justified in these terms: as metadata that a sub can advertise
as part of its API.  It should then be possible to populate these fields
appropriately on any sub, whether or not it uses a signature.  XS subs
should be able to provide this metadata, Perl subs not using signatures
should also be able to, and even Perl subs that are implemented using
signatures should be able to set these fields differently from what the
signature implies.  Where a signature implies a specific value for one
of the metadata fields, it is OK to have some mode in which the field
is by default set according to the signature for subs that use one.
But this mode shouldn't be the default under existing pragmata, because
for this information to be advertised in public metadata would be a
significant change in the semantics of existing signatures.

>* cv_min_arity($coderef)
>* cv_max_arity($coderef)

Treating these as sub metadata, what's the intended semantic for callers?
Clearly there can't be a guarantee that the sub will accept any number
of arguments in the advertised range, because there isn't a well-defined
concept of accepting arguments.  A set of arguments can always be rejected
for semantic reasons other than their count.  Is the sub guaranteeing that
it will die if given a number of arguments outside the stated range?
It doesn't seem all that useful to merely have a guaranteed way of
generating an exception; we've already got die() if we want to do that.

It seems to me that this metadata isn't at all useful to other code
at runtime.  Its real value is as an advisory to the programmer:
a development tool can introspect on the sub to catch dubious calls
prior to runtime.  Of course, the value is limited by the fact that a
call such as "foo(bar())" could pass any number of arguments to foo(),
due to list context.  Prototypes already provide arity advice that
development tools can (and perl itself does at compile time) pick up on,
and by affecting context they make arity mismatches spottable at a much
higher proportion of callsites.  So the arity metadata that you propose
isn't looking compelling.

The proper default, for a sub that doesn't elect to supply specific arity
metadata (a sub that "has no signature" in your proposal), depends on the
intended usage of the metadata.  If it's about guaranteeing to signal an
exception for bad argument lists then your proposed 0/Inf default is fine.
But if it's advice to the programmer, then it's more useful to have a
distinct state that says "this sub does not supply this information".
It is useful for the programmer to distinguish between "this sub puts
no restriction on the number of arguments" and "argument count metadata
is not available for this sub".

>* cv_slurpy($coderef)

Many of the same issues apply.  The existence of a hash-like tail to the
argument list structure is useful information to the callsite programmer
during development, but not really usable by code at runtime.  The same
information is already advertised in some form through prototypes,
and prototypes make it easier to apply this knowledge.  One should
distinguish between "no hash-like tail" and "information not available".

Knowing that there is a hash-like tail on its own isn't much use: to apply
the knowledge requires knowing at what parameter index this tail starts.
Your proposed arity metadata doesn't cover this.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About