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

Re: RFC: core sub signature introspection

Thread Previous
Chad Granum
November 23, 2016 22:58
Re: RFC: core sub signature introspection
Message ID:
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 <> 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
> made".
> 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.
> -zefram

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