Front page | perl.perl5.porters |
Postings from November 2016
Re: RFC: core sub signature introspection
Thread Previous
|
Thread Next
From:
Aaron Crane
Date:
November 23, 2016 20:51
Subject:
Re: RFC: core sub signature introspection
Message ID:
CACmk_ts2We66dXcWuppBVphGBL9hNjtLXzA=5hhnBd3M6MuXEQ@mail.gmail.com
Zefram <zefram@fysh.org> 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;
return;
}
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 ** http://aaroncrane.co.uk/
Thread Previous
|
Thread Next