-
Notifications
You must be signed in to change notification settings - Fork 542
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
[EXPERIMENT] pluggable keyword API #13199
Comments
From @rjbsperl 5.12.0 introduced the "pluggable keyword" API. Although perlexperiment We should determine acceptance criteria, then track them. (Subordinate bugs can be hung off this one.) See also the original(?) ticket for pluggable keywords, [perl #70263] -- |
From zefram@fysh.orgRicardo SIGNES wrote:
That API turned out to be a poor design, and we should ultimately remove -zefram |
The RT System itself - Status changed from 'new' to 'open' |
From @maukeOn 25.08.2013 11:31, Zefram wrote:
Devel::CallParser solves a different problem. I can only use it to For example: if I want to reimplement 'sub', I need to accept a bareword Assuming I can do this manually by bypassing D:CP and calling perl's Finally, the whole thing won't be a statement by itself, so the user I'm thinking of this: sub mysub {} mysub plus { # compiled as: Also, this would make something like my $wtf = mysub foo { return 42; }; valid syntax. (Equivalent to: BEGIN { *foo = sub { return 42; }; } ) All of this is unlike the 'sub' builtin, which can be approximated very In short: If I haven't misunderstood how D:CP works, then the pluggable (And I still want the KEYWORD_PLUGIN_NOOP patch to go in because it -- |
From zefram@fysh.orgLukas Mai wrote:
The breakthrough that led to Devel::CallParser is the understanding that
That's orthogonal to how the namespace is managed. You need those
When using D:CP for this sort of thing, you'll also want to use It's sane to argue that the eventual API should make it easier than
That's what the CALLPARSER_STATEMENT flag in the D:CP API is for.
You have misunderstood much of D:CP. -zefram |
From @ikegamiOn Sun, Aug 25, 2013 at 7:32 AM, Lukas Mai <plokinom@gmail.com> wrote:
You should have a look at Syntax::Feature::Loop. That's pretty much exactly (It actually provides C<< loop { ... } >>, but C<< mysub NAME { ... } >> |
From @ikegamiOn Sun, Aug 25, 2013 at 7:32 AM, Lukas Mai <plokinom@gmail.com> wrote:
That's not the case. For example, the aformentioned C<< loop BLOCK >> does |
From @maukeOn 25.08.2013 15:09, Zefram wrote:
Fair enough. I've been thinking about creating a branch to convert 1) There's no documentation that tells you how you actually integrate it # to generate header prior to XS compilation perl -MDevel::CallParser=callparser0_h \ What exactly is "prior"? Do I do this once and check the file in? Or is 2) Function::Parameters is a lexical pragma. Does D:CP provide lexical -- |
From @cpansproutOn Wed Aug 28 12:53:28 2013, plokinom@gmail.com wrote:
You can use Lexical::Var for that. Or use Perl’s own lexical sub -- Father Chrysostomos |
From @doyOn Wed, Aug 28, 2013 at 02:14:14PM -0700, Father Chrysostomos via RT wrote:
This actually doesn't work yet, because prototypes aren't parsed on -doy |
From zefram@fysh.orgLukas Mai wrote:
Yeah. That bit's tricky. ExtUtils::CBuilder really isn't set up to
You generate the header during the build process. The header is specific
That's between you and ExtUtils::MakeMaker. I've never done it that way;
You can if you like, but then D:CP would be a configure_requires.
No, D:CP does not address exporting. It just attaches magic to a For a while I thought lexical exporting was the way forward. I therefore wrote Lexical::Import, which interfaces to a standard (If you have a backcompat requirement to lexically export from a So you see my recommended mechanism involves composing a bunch of modules -zefram |
From @doyOn Wed, Aug 28, 2013 at 10:24:43PM +0100, Zefram wrote:
Parse::Keyword has an example of a build process that works on Windows, -doy |
From @cpansproutOn Wed Aug 28 14:17:43 2013, doy@tozt.net wrote:
I think you are confusing call parsers and call checkers; I could be wrong. I believe 5.18.1 addressed the latter: =item * Lexical constants (C<my sub a() { 42 }>) no longer crash when inlined. =item * Parameter prototypes attached to lexical subroutines are now respected when -- Father Chrysostomos |
From @doyOn Wed, Aug 28, 2013 at 03:28:22PM -0700, Father Chrysostomos via RT wrote:
Prototypes do work now, but Devel::CallParser still doesn't seem to. I'm -doy |
From @cpansproutOn Wed Aug 28 15:46:25 2013, doy@tozt.net wrote:
If you have a test case, could you file a separate bug? -- Father Chrysostomos |
From @doyOn Wed, Aug 28, 2013 at 04:40:19PM -0700, Father Chrysostomos via RT wrote:
I've boiled this down to a test case, but it's not really clear if it's -doy |
From @doy |
From @ikegamiOn Wed, Aug 28, 2013 at 3:52 PM, Lukas Mai <plokinom@gmail.com> wrote:
For both, take a look at Syntax::Feature::Loop. Feel free to ask me if you |
From @maukeOn 29.09.2013 17:46, Eric Brine wrote:
I've given up on D:CP for now. It simply doesn't provide the right I've found a few weird things in Syntax::Feature::Loop, though: % perl -we 'use syntax "loop"; loop()' That's not very helpful. (Also, why 2 syntax errors?) % perl -we 'use syntax "loop"; &loop()' Why is it trying to call Syntax::Feature::Loop::loop instead of % perl -we 'use syntax "loop"; sub loop {} &loop()' That simply shouldn't happen. I have a perfectly fine &main::loop right -- |
From @ikegamiOn Sun, Sep 29, 2013 at 4:15 PM, Lukas Mai <plokinom@gmail.com> wrote:
Not helpful? It's the exact same error message found elsewhere.
In fact, the error is emitted by Perl itself. I'll look into why it's
There's a difference between existing and being defined. While the sub
Yes, but you said to use the one from S::F::L. Defining a sub doesn't
|
From @ikegamiOn Mon, Sep 30, 2013 at 9:29 AM, Eric Brine <ikegami@adaelis.com> wrote:
% perl -we 'use syntax "loop"; sub loop {} &loop()'
ah, nevermind, I get your point here. I'll don't know if that's an issue $ perl -Mfeature=lexical_subs -M-warnings=experimental -wE'my sub lc { "b" |
From @doyOn Sat, Sep 28, 2013 at 02:51:52PM -0400, Jesse Luehrs wrote:
And reported as a bug against Devel::CallParser here: -doy |
Migrated from rt.perl.org#119455 (status was 'open')
Searchable as RT119455$
The text was updated successfully, but these errors were encountered: