Proposed new function - lex_scan_ident()

I'd like to propose a new lexer/parser function:

  SV *lex_scan_ident()

I have copypasted it into my Future/AsyncAwait.xs from various
inspirations of MAUKE, and it has proven quite stable and useful across
a few modules now, so I think it about time we moved it to core.

  https://metacpan.org/source/PEVANS/Future-AsyncAwait-0.29/lib/Future/AsyncAwait.xs#L1892

If nobody objects by this time next week I'll have a go at sending a
patch.

-- 
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk      |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/
0
leonerd
7/5/2019 2:37:00 PM
perl.perl5.porters 47703 articles. 1 followers. Follow

7 Replies
19 Views

Similar Articles

[PageSpeed] 21

On 7/5/19 10:37 AM, Paul "LeoNerd" Evans wrote:
> I'd like to propose a new lexer/parser function:
> 
>    SV *lex_scan_ident()
> 
> I have copypasted it into my Future/AsyncAwait.xs from various
> inspirations of MAUKE, and it has proven quite stable and useful across
> a few modules now, so I think it about time we moved it to core.
> 
>    https://metacpan.org/source/PEVANS/Future-AsyncAwait-0.29/lib/Future/AsyncAwait.xs#L1892
> 
> If nobody objects by this time next week I'll have a go at sending a
> patch.
> 

If you send a patch via perlbug, we can always create a smoke-me branch 
to try it out.
0
jkeenan
7/5/2019 2:42:08 PM
On Fri, Jul 5, 2019 at 4:37 PM Paul "LeoNerd" Evans
<leonerd@leonerd.org.uk> wrote:
>
> I'd like to propose a new lexer/parser function:
>
>   SV *lex_scan_ident()
>
> I have copypasted it into my Future/AsyncAwait.xs from various
> inspirations of MAUKE, and it has proven quite stable and useful across
> a few modules now, so I think it about time we moved it to core.
>
>   https://metacpan.org/source/PEVANS/Future-AsyncAwait-0.29/lib/Future/AsyncAwait.xs#L1892
>
> If nobody objects by this time next week I'll have a go at sending a
> patch.

Yes this sounds useful.

Leon
0
fawaka
7/5/2019 3:00:14 PM
=D0=BF=D1=82, 5 =D0=B8=D1=8E=D0=BB. 2019 =D0=B3. =D0=B2 17:37, Paul "LeoNer=
d" Evans <leonerd@leonerd.org.uk>:
> I have copypasted it into my Future/AsyncAwait.xs from various
> inspirations of MAUKE

Will it actually be used in core? If not, maybe you just ship as a
separate module to CPAN, and just depend on it to provide you and
others this reusable code block? Modules are created just for this,
unlike PHP.

Best regards,
Sergey Aleynikov
0
sergey
7/7/2019 10:39:04 AM
On Sun, Jul 7, 2019 at 12:39 PM Sergey Aleynikov
<sergey.aleynikov@gmail.com> wrote:
> Will it actually be used in core? If not, maybe you just ship as a
> separate module to CPAN, and just depend on it to provide you and
> others this reusable code block? Modules are created just for this,
> unlike PHP.

If only that were a realistic option. It's not really for reusable C
code though.

Leon
0
fawaka
7/7/2019 10:45:10 AM
=D0=B2=D1=81, 7 =D0=B8=D1=8E=D0=BB. 2019 =D0=B3. =D0=B2 13:45, Leon Timmerm=
ans <fawaka@gmail.com>:
> If only that were a realistic option. It's not really for reusable C
> code though.

We at $work have developed a full binary- and source- code c/c++
dependency-sharing framework, it's current version is released as
https://metacpan.org/pod/XS::Install. It has rather high prerequisites
(a working c++ compiler and perl 5.22+), but it shows that this is not
something impossible, if you need c code sharing. ExtUtils::Depends
does the same thing with less dependencies but with more hassle.

Best regards,
Sergey Aleynikov
0
sergey
7/7/2019 12:36:10 PM
On Sun, 7 Jul 2019 13:39:04 +0300
Sergey Aleynikov <sergey.aleynikov@gmail.com> wrote:

> =D0=BF=D1=82, 5 =D0=B8=D1=8E=D0=BB. 2019 =D0=B3. =D0=B2 17:37, Paul "LeoN=
erd" Evans
> <leonerd@leonerd.org.uk>:
> > I have copypasted it into my Future/AsyncAwait.xs from various
> > inspirations of MAUKE =20
>=20
> Will it actually be used in core? If not, maybe you just ship as a
> separate module to CPAN, and just depend on it to provide you and
> others this reusable code block?

Core ships loads of things it doesn't itself rely on. In fact, that
could be said to be the point of core - to act as the base for CPAN to
build on.

That said, I can see a potential problem in that if core's parser
doesn't use the same function, there is the possibility of different
behaviours. This can hopefully be handled by enough tests to ensure
both parsers/scanners give the same answers to a given set of inputs.

> Modules are created just for this, unlike PHP.

And as Leon T points out, they don't tend to work anywhere near as
nicely for C->C dependencies, as Perl->Perl ones.

--=20
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk      |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/
0
leonerd
7/7/2019 1:48:20 PM
On Fri, Jul 05, 2019 at 03:37:00PM +0100, Paul "LeoNerd" Evans wrote:
> I'd like to propose a new lexer/parser function:
> 
>   SV *lex_scan_ident()
> 
> I have copypasted it into my Future/AsyncAwait.xs from various
> inspirations of MAUKE, and it has proven quite stable and useful across
> a few modules now, so I think it about time we moved it to core.
> 
>   https://metacpan.org/source/PEVANS/Future-AsyncAwait-0.29/lib/Future/AsyncAwait.xs#L1892
> 
> If nobody objects by this time next week I'll have a go at sending a
> patch.

If it can be done as a simple wrapper around S_scan_ident()
S_parse_ident() or something similar (passing PL_bufptr for s, etc)
I'd have no objection.

It is possible to share C code - Time::HiRes does it, Imager does it,
generally by moving function pointers around.

Tony
0
tony
7/8/2019 4:11:06 AM
Reply: