Signature parsing compiler functions

--Sig_/BObcJIqzF_VHAr7tN+xsNh5
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Currently in the implementation of Future::AsyncAwait's syntax parsing,
I have to manually handle 'sub NAME { BLOCK }' parsing, because I need
to get at the optree before it's been checked and installed into the
CV, and no bits of perl API currently exist to let me do that.

  https://metacpan.org/source/PEVANS/Future-AsyncAwait-0.10/lib/Future/Asyn=
cAwait.xs#L825

As a result, what I currently do is special-case handling of two cases

  async sub NAME { BLOCK }   # as a statement
  async sub { BLOCK }        # as an expression

I specifically don't handle prototypes, attributes, or signatures at
present.

While we're on the subject of signatures in other threads, I wonder if I
could ask for a little bit of extra API to help me here. What would be
very nice is a pair of functions whose prototypes might look something
like

  void *parse_signature(void);  /* returns a "cookie" */
  OP *gen_signature_unpack(void *cookie);

The idea here being that at the point in syntax where I might encounter
a signature I can just call the first, and if it returned a non-NULL
then when I'm about to parse the block I first call the second which
gives me the initial bit of optree which performs whatever steps are
necessary. The two can communicate via that void *cookie.

As-yet unanswered questions are whether these functions would need any
more arguments to tell them what to do, what implicit assumptions they
make about interpreter variables, and also how they handle errors - who
frees the cookie if we abort?

The addition of some functions of roughly this shape would be very
helpful to me to enabling async (named or anonymous) subs with
signatures, by offloading the parsing back to perl itself.

--=20
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk      |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/

--Sig_/BObcJIqzF_VHAr7tN+xsNh5
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----

iF0EARECAB0WIQQACtfoNPkrOD+dkiu8tLZMLxwGjQUCWgo8PQAKCRC8tLZMLxwG
jVSwAJ4vOgeATpmCKBihKNPhr1t3bQm7xwCePi8aO+FfehTqEZp1EUK5xuJ4McA=
=mHdF
-----END PGP SIGNATURE-----

--Sig_/BObcJIqzF_VHAr7tN+xsNh5--
0
leonerd
11/14/2017 12:43:41 AM
perl.perl5.porters 46731 articles. 0 followers. Follow

1 Replies
2 Views

Similar Articles

[PageSpeed] 11

Paul "LeoNerd" Evans wrote:
>The idea here being that at the point in syntax where I might encounter
>a signature I can just call the first, and if it returned a non-NULL
>then when I'm about to parse the block I first call the second which
>gives me the initial bit of optree which performs whatever steps are
>necessary.

It's impossible to separate these two phases.  Signatures contain
arbitrary expressions, and the only way to parse them is to generate
their ops.  Presumably you wanted to install op checkers that would
modify the optree as it's built; in fact you'll need to have your op
checkers in place before parsing the signature.

The original implementation of signatures did have a procedural interface
for parsing them:

    OP *parse_subsignature(void);

You call it after lexing the opening "(" of the signature, it parses the
interior, returns with the lexer facing either the ")" or a syntax error,
and returns the ops that perform the argument checking and unwrapping.

My intent was always that that would become an API function, but I didn't
actually mark it as API.  I don't remember the thought process there, but
it was probably just that we hadn't discussed a parsing API as part of the
rapidly-formed consensus on an initial version of signatures, so I didn't
perceive a mandate to add an API function, even on the experimental basis.

parse_subsignature() wasn't merely an orphaned API function, though.
It was the actual implementation, since I'd found it easier to parse
signatures in a recdescent manner than through yacc.  A subsequent edit
(not by me) moved the bulk of the parsing work into the yacc grammar,
and incidentally removed this function.  (And introduced [perl #131777].)

I'd like there to be an API function for procedural code to invoke
signature parsing, and I'm satisfied with the calling convention of the
original parse_subsignature() for that purpose.  Note that it can exist
as an API regardless of which way the parsing is implemented internally.
It is arguable that having such an API function should be a prerequisite
for removing experimental status from signatures, but the other parse_*()
functions are still experimental in their own right.

-zefram
0
zefram
11/14/2017 12:11:17 PM
Reply: