Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

signature parsing API function #16261

Closed
p5pRT opened this issue Nov 20, 2017 · 6 comments
Closed

signature parsing API function #16261

p5pRT opened this issue Nov 20, 2017 · 6 comments

Comments

@p5pRT
Copy link
Collaborator

@p5pRT p5pRT commented Nov 20, 2017

Migrated from rt.perl.org#132474 (status was 'pending release')

Searchable as RT132474$

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Nov 20, 2017

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/zsh

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Jan 18, 2018

From @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" Evans

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

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Jan 18, 2018

The RT System itself - Status changed from 'new' to 'open'

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Feb 11, 2019

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 per

  https://rt.cpan.org/Public/Bug/Display.html?id=123465

--
Paul "LeoNerd" Evans

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

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Jul 22, 2019

From @khwilliamson

Thanks, committed as
996b0cb
--
Karl Williamson

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Jul 22, 2019

@khwilliamson - Status changed from 'open' to 'pending release'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant
You can’t perform that action at this time.