Front page | perl.perl5.porters |
Postings from November 2016
Re: RFC: core sub signature introspection
From: Chad Granum
November 23, 2016 22:58
Re: RFC: core sub signature introspection
Message ID: CAJFr3kvBJ-f-skeHJRptZmYJpZPvjHODoMRkSct_7hypjaJayw@mail.gmail.com
I could see this being useful for automatic documentation of some sorts.
Being able to generate that we have x functions, function xyz takes between
0 and 99 arguments, the arguments are named $a, $b, @the_rest.
In fact many languages have auto-generated docs that make sure of signature
In run-time code I have less opinion on this.
On Wed, Nov 23, 2016 at 2:02 PM, Zefram <email@example.com> wrote:
> 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.