Repository navigation
signature parsing API function #16261
Description
Activity
From zefram@fysh.org
Created by zefram@fysh.org
It would be nice to have a C API function for parsing subroutine
signatures, along the lines of the existing parse_fullstmt() et al.
This would be particularly useful for CPAN modules that implement
some variant kind of subroutine, where it should be reasonably easy to
incorporate all parts of the baseline syntax for subroutine bodies.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'm satisfied with the calling convention of the original
parse_subsignature(), for the purpose of a parsing API. 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. However, the other
parse_*() functions are still experimental in their own right.Perl Info
Flags: category=core severity=wishlist Site configuration information for perl 5.27.5: Configured by zefram at Fri Oct 20 23:24:00 BST 2017. Summary of my perl5 (revision 5 version 27 subversion 5) configuration: Platform: osname=linux osvers=3.16.0-4-amd64 archname=x86_64-linux-thread-multi uname='linux barba.rous.org 3.16.0-4-amd64 #1 smp debian 3.16.43-2+deb8u2 (2017-06-26) x86_64 gnulinux ' config_args='-des -Dprefix=/home/zefram/usr/perl/perl_install/perl-5.27.5-i64-f52 -Duselargefiles -Dusethreads -Uafs -Ud_csh -Uusesfio -Uusenm -Duseshrplib -Dusedevel -Uversiononly -Ui_db' hint=recommended useposix=true d_sigaction=define useithreads=define usemultiplicity=define use64bitint=define use64bitall=define uselongdouble=undef usemymalloc=n default_inc_excludes_dot=define bincompat5005=undef Compiler: cc='cc' ccflags ='-D_REENTRANT -D_GNU_SOURCE -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2' optimize='-O2' cppflags='-D_REENTRANT -D_GNU_SOURCE -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include' ccversion='' gccversion='4.9.2' gccosandvers='' intsize=4 longsize=8 ptrsize=8 doublesize=8 byteorder=12345678 doublekind=3 d_longlong=define longlongsize=8 d_longdbl=define longdblsize=16 longdblkind=3 ivtype='long' ivsize=8 nvtype='double' nvsize=8 Off_t='off_t' lseeksize=8 alignbytes=8 prototype=define Linker and Libraries: ld='cc' ldflags =' -fstack-protector-strong -L/usr/local/lib' libpth=/usr/local/lib /usr/lib/gcc/x86_64-linux-gnu/4.9/include-fixed /usr/include/x86_64-linux-gnu /usr/lib /lib/x86_64-linux-gnu /lib/../lib /usr/lib/x86_64-linux-gnu /usr/lib/../lib /lib libs=-lpthread -lnsl -ldb -ldl -lm -lcrypt -lutil -lc perllibs=-lpthread -lnsl -ldl -lm -lcrypt -lutil -lc libc=libc-2.19.so so=so useshrplib=true libperl=libperl.so gnulibc_version='2.19' Dynamic Linking: dlsrc=dl_dlopen.xs dlext=so d_dlsymun=undef ccdlflags='-Wl,-E -Wl,-rpath,/home/zefram/usr/perl/perl_install/perl-5.27.5-i64-f52/lib/5.27.5/x86_64-linux-thread-multi/CORE' cccdlflags='-fPIC' lddlflags='-shared -O2 -L/usr/local/lib -fstack-protector-strong' @INC for perl 5.27.5: /home/zefram/usr/perl/perl_install/perl-5.27.5-i64-f52/lib/site_perl/5.27.5/x86_64-linux-thread-multi /home/zefram/usr/perl/perl_install/perl-5.27.5-i64-f52/lib/site_perl/5.27.5 /home/zefram/usr/perl/perl_install/perl-5.27.5-i64-f52/lib/5.27.5/x86_64-linux-thread-multi /home/zefram/usr/perl/perl_install/perl-5.27.5-i64-f52/lib/5.27.5 Environment for perl 5.27.5: HOME=/home/zefram LANG (unset) LANGUAGE (unset) LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=/home/zefram/usr/perl/perl_install/perl-5.27.5-i64-f52/bin:/home/zefram/usr/perl/util:/home/zefram/pub/x86_64-unknown-linux-gnu/bin:/home/zefram/pub/common/bin:/usr/bin:/bin:/usr/local/bin:/usr/games PERL_BADLANG (unset) SHELL=/usr/bin/zshFrom @leonerd
On Mon, 20 Nov 2017 07:06:06 -0800
Zefram (via RT) <perlbug-followup@perl.org> wrote:It would be nice to have a C API function for parsing subroutine
signatures, along the lines of the existing parse_fullstmt() et al.
This would be particularly useful for CPAN modules that implement
some variant kind of subroutine, where it should be reasonably easy to
incorporate all parts of the baseline syntax for subroutine bodies.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.I'd very much like such a function indeed, so I can call it from the
Future::AsyncAwait keyword implementation....
I'm satisfied with the calling convention of the original
parse_subsignature(), for the purpose of a parsing API. 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.
However, the other parse_*() functions are still experimental in
their own right.So, what's required to make this exist then? Beyond "sit and wait for
it", what can I do to assist?--
Paul "LeoNerd" Evansleonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/The RT System itself - Status changed from 'new' to 'open'
From @leonerd
On Thu, 18 Jan 2018 18:45:52 +0000
"Paul \"LeoNerd\" Evans" <leonerd@leonerd.org.uk> wrote:It is arguable that having such an API function should be a
prerequisite for removing experimental status from signatures.
However, the other parse_*() functions are still experimental in
their own right.So, what's required to make this exist then? Beyond "sit and wait for
it", what can I do to assist?*ping*
Any update on this? It's been a year and a major perl version, with no
progress in sight.It would be nice to have some way to get signature parsing out of core
perl, because then I could support signatured `async sub`s, as perhttps://rt.cpan.org/Public/Bug/Display.html?id=123465
--
Paul "LeoNerd" Evansleonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/From @khwilliamson
Thanks, committed as
996b0cb
--
Karl Williamson@khwilliamson - Status changed from 'open' to 'pending release'
Migrated from rt.perl.org#132474 (status was 'pending release')
Searchable as RT132474$