Introspection of checks for function signatures (parameters, return), class fields, etc.

[zmughal]

In addition to making the checks themselves be first class as brought up in https://github.com/orgs/Perl-Oshun/discussions/6, this information should also be available at runtime for introspection via the MOP.

This has some precedent on CPAN:

• https://metacpan.org/pod/Function::Parameters::Info
• https://metacpan.org/pod/Sub::Meta
• https://metacpan.org/pod/Function::Interface::Info

It also would allow for a kind of check that is not yet defined in the spec
which is to check CODE parameters and return:

• https://metacpan.org/pod/Types::TypedCodeRef

And would allow for some decoupling in the implementation of Design by Contract https://github.com/orgs/Perl-Oshun/discussions/41 (any kind of verifier could be used by the user).

Keywords: MOP, meta, metadata, introspection, coderef

[zmughal]

@happy-barney, correct me if I'm wrong, but this may be what you were describing when you said:

• Callback [ Check, Argument Checks ... ] - transform parameter check into
  check describing function
  sub :returns(Check) (Argument Checks ...)

at https://www.nntp.perl.org/group/perl.perl5.porters/2023/05/msg266478.html.

[happy-barney]

Depends on what do you understand as introspection. I understand it like:

sub foo ...;

my $introspection = introspect (\ &foo);
say qq (It checks its return value: ${\ $introspection->on_return->description }); 

What I described is:

declare check Getopt::Long::Option_Handler as Callback [ Any, Str, Optional [ Str ] ];
sub foo :returns(Foo) ($name :check(Str), $value :check(Str));
sub bar :returns(Foo) ($name :check(Str | Undef), $value :check(Str));

my $var :check(Option_Handler) = \ &foo; # will pass
my $var :check(Option_Handler) = \ &bar; # will fail

Hmm, and here another example why another attribute will suit better:

sub bar :contract(contract_of (\ &foo) ($name, $value) { ... } # will copy :returns and all arguments checks as well

[zmughal]

Right, that's what I mean by introspection. My point is that matching against coderef signatures will necessarily require having data around that could also be used for introspection so might as well make it available to the programmer --- they reinforce each other as features. This is how that Types::TypedCodeRef module works.

[zmughal]

CC: @kfly8, @ybrliiu as they have done many interesting things here with tracking the sub information for checking in other places (e.g., for defining an interface).

[kfly8]

Oshun is a fascinating project, and I'm delighted to have been mentioned.
(I honestly didn't expect to be mentioned, so I was slow to notice.)

I might touch upon topics outside the scope of this discussion, but I'll briefly share my thoughts. I hope you can be of some help.

I believe that the Introspection API, which retrieves meta-information about functions, including anonymous functions, such as their arguments and return values, is crucial.

Regarding the referenced Function::Interface and Sub::Meta:

• I implemented Sub::Meta based on reflections from Function::Interface.
  • Simply put, there was a lot of overlap between Function::Interface::Info and Function::Parameters::Info, and I felt it was inconvenient for users to learn multiple ways to handle meta-information.
  • Moreover, if we could easily handle function meta-information through a common Introspection API, I believed it would become easier for others, not just myself, to develop user-friendly libraries.
    • Types::TypedCodeRef is an example that utilized Sub::Meta.
• My thoughts are influenced by PSGI/Plack and the type checking in Ruby3.
  • In Ruby3, RBS, which represents function meta-information, is bundled. Sub::Meta was created with this RBS in mind.
  • And then, type checkers like steep and sorbet exist separately and aren't bundled with Ruby3.
• I believe this approach fosters both diversity and order simultaneously.

That's all for now!

[zmughal]

The current RFC 0022 for metaprogramming does not address this per Perl/PPCs#25 (comment).

[zmughal]

This will also be needed for multimethods.

[zmughal]

I also wonder how this would work with signature of something like around:

sub around(
  METHOD_NAME $method_name,                          # * Str that matches a valid method name
                                                     #   (maybe check the package stash too?)
  CODEREF[ [
      coderef_check_with_signature_of($method_name), # * This is another CODEREF
      parameters_of($method_name)                    # * Flattens all the checks
    ] => Any ] ) {                                   # * `around` allows return type to change
                                                     #   (though that would be bad design)
  ...
}

or if this should be part of a DbC-style precondition?

[zmughal]

That bit reminds me of the multisig feature of https://metacpan.org/pod/Type::Params#multiple-ArrayRef.

I think the closest to what I'm getting with the around is that a signature could inherit the contract of another, but modify it it (if we did this right, it should be modified to be compatible / substitutable with whatever check it is inheriting --- and have an explicit escape hatch for code that is less strict because it existed before any of this).

[happy-barney]

yeah, that's quite similar. But example given by Type::Params should be treated by signatures (have another gist about that: https://gist.github.com/happy-barney/15ff8755e7fd8ef94069ee4f667975df

[zmughal]

These gists are all good! I especially like the comparison with other languages. Named arguments are something that would be useful for interoperability via Inline::Python and R which expose these at the C level. I work around that interoperability by creating a small object to hold the pairs in Perl and convert on the other side.

Do you have a list of all the gists or could you put them all in a single place? No rush, I also want to see that idea about independent symbol space.

[happy-barney]

I'm working on single space, but it's slow :-( There are too many synergies. For example independent symbol spaces (I'll use that, sounds better then separated), as expected to use by Oshun, leads to refactoring of attributes (putting all of them in C code at same level as lvalue)

Meanwhile list what I have prepared (I think all of them were already sent to p5p - without much of response):

• https://gist.github.com/happy-barney/e40fef7a56df4cbd309e03bcf8ee9503
• https://gist.github.com/happy-barney/ec9f7d00bb3d83a9ca123d2c736fb04c
• https://gist.github.com/happy-barney/aecf0fa6cb5ba1d427a3f578a7bb4806
• https://gist.github.com/happy-barney/8daa827fb641e674643bdaeb803296f2
• https://gist.github.com/happy-barney/b92c2ff38d113c8f5e28f53a2592c0b3
• https://gist.github.com/happy-barney/ce4b8e39e42bde8bfa0c491e444a90f1
• https://gist.github.com/happy-barney/b92755cce092a138cb40a084391f5897

[happy-barney]

and first iteration of independent symbol spaces: https://github.com/happy-barney/perl-wish-list/blob/master/independent-symbol-spaces/README.md