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

Re: RFC: core sub signature introspection

Thread Previous | Thread Next
November 23, 2016 22:03
Re: RFC: core sub signature introspection
Message ID:
Aaron Crane wrote:
>I'm aware that this is your view, but I respectfully disagree.

You have missed the point of signatures.  They are a convenience to
the programmer writing a sub.  If they become strongly tied to metadata
intended for users of the sub, a fortiori if the signature itself becomes
advertised metadata, then they are no longer convenient.  They instead
become a constraint that the programmer must satisfy.

>don't think that lacuna is a reason not to offer introspection on
>subroutines where the information *is* available.

This lacuna only exists because you are putting the cart before the
horse.  If we start in the right place by thinking about metadata, we
can readily add new metadata fields to the XPVCV structure or as MAGIC
structures attached to the CV.  (The choice between the two boils down
to how common we think the metadata will be.)  These representations
are equally applicable to any kind of CV: XS sub or Perl sub (whether
or not it uses a signature).  The XS language can acquire new keywords
to declare the metadata ("ADVERTISED_ARITY: 2"), and the Perl language
can use attributes for the same purpose (":advertised_arity(2)").

>Here's a sketch of one such use case:

That's an interesting kind of use.  It's not really seeking a minimum
arity, it's after a *recommended* arity.  That does seem a more useful
semantic than any concept of minimum or maximum, or indeed the slurpiness
information that you proposed.  I'd be reasonably happy with adding such
a metadata field.  It would be a single arity value, not a range, never
infinite, and would have to have a null state meaning "no recommendation

See how thinking about this from the user's perspective has yielded better
semantics than starting from the signature?  That's not a coincidence.

Under an appropriate pragma, the recommended arity could readily default
to the arity imposed by a signature, where the signature contains only
mandatory parameters.  It would be rather dodgy to try to intuit a
recommended arity where a signature offers more than one option.

>                In addition, Matthew Horsfall has suggested that the
>names of formal parameters should be introspectable, and I'm planning
>to provide that also.

Again, we need to think about use cases.  What does it mean for a
parameter position to be associated with a specific name, as advertised
by the sub?  There are multiple possible answers.  I won't explore them
all here, but let's just consider the most straightforward, that the name
has no meaning for running code but is a hint to the callsite programmer,
which could be displayed by an editor.  What the sub is advertising,
then, is not `the name' of a parameter, but *a hint* (in name form)
as to the purpose of a parameter.  Once again, this metadata is equally
applicable to XS subs, and to Perl subs regardless of whether they're
written using a signature.

The hint name of a parameter will very often coincide with the name
that a sub's implementation uses internally for the variable containing
the parameter value.  As a convenience, under some pragma we could
default to advertising hints derived from the parameter declaration in
the implementation.  We can do that in XS, where parameter declarations
are governed by the XS language, and we can do it for Perl subs written
using signatures.  But even in these cases it must be possible to specify
hint names separate from the parameter declarations: the desired hint
name is not always the same as the internal variable name.


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