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

Re: RFC: core sub signature introspection

Thread Previous | Thread Next
Aaron Crane
November 23, 2016 20:51
Re: RFC: core sub signature introspection
Message ID:
Zefram <> wrote:
> 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.

I'm aware that this is your view, but I respectfully disagree.

> 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,

Yes, I agree that it's suboptimal that XS subs are unable to
programmatically expose this sort of information about their API; and
I'd welcome any proposal for how XS subs could be offered a way to do
so (other than using prototypes, since those affect parsing). But I
don't think that lacuna is a reason not to offer introspection on
subroutines where the information *is* available.

>>* 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.

But that doesn't mean that arity is an uninteresting piece of
information about a subroutine.

> It seems to me that this metadata isn't at all useful to other code
> at runtime.

Here's a sketch of one such use case:

sub iterate ($array, $code) {
    my $arity = cv_min_arity($code) or die;
    my @values = @$array;
    push @values, undef while @values % $arity;
    $code->(splice @values, 0, $arity) while @all;

iterate(\@array, sub ($x, $y, $z) { ... });

> 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".

I'm happy with the idea that the presence or absence of arity metadata
should also be introspectable.

>>* cv_slurpy($coderef)
> 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.

This is very useful feedback; thank you.

I should mention that, following offline discussion with Dave M, I've
decided not to try and merge this at the moment: Dave is planning to
do further work on the implementation of sub signatures, and I don't
want to increase the burden on him by effectively requiring him to
maintain the introspection code.

Once his signature work is complete, I intend to redo this
introspection interface, and present it as a revised proposal. I will
certainly take account of your points that both the presence of arity
metadata and the start position of any hash-like tail should be
introspectable. In addition, Matthew Horsfall has suggested that the
names of formal parameters should be introspectable, and I'm planning
to provide that also.

Aaron Crane **

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