Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Perl: porters

[perl #108286] Wishlist: Overridable keywords

 

 

Perl porters RSS feed   Index | Next | Previous | View Threaded


perlbug-comment at perl

Apr 21, 2012, 10:41 PM

Post #1 of 21 (364 views)
Permalink
[perl #108286] Wishlist: Overridable keywords

On Wed Apr 04 13:53:55 2012, ikegami [at] adaelis wrote:
> The builtin "if" should expect the following to follow it (ignoring
> whitespace)
>
> "(" EXPR ")" BLOCK ( "elsif" "(" EXPR ")" BLOCK )* ( "else" BLOCK )?
>
> None of those tokens should be overridable when parsing that rule
(although
> EXPR and BLOCK may use overridden tokens).

In that case, is there any reason why elsif needs to be a reserved word
outside of that context?

I’m also trying to plan ahead with regard to adding all keywords to the
CORE:: namespace.

It should be possible in the future for the ‘if’ keyword to be
implemented as a CV named &CORE::if, which has its own custom parser
that eats the elsif and else keywords.

But it won’t make much sense for there to be a &CORE::elsif subroutine.
It would just be a stub that produces a syntax error when inlined.
Maybe that does make sense. Then we could always change it later.

--

Father Chrysostomos


perlbug-comment at perl

Apr 22, 2012, 1:56 PM

Post #2 of 21 (363 views)
Permalink
[perl #108286] Wishlist: Overridable keywords [In reply to]

On Sun Apr 22 13:25:19 2012, ikegami [at] adaelis wrote:
> On Sun, Apr 22, 2012 at 1:41 AM, Father Chrysostomos via RT <
> perlbug-comment [at] perl> wrote:
>
> > On Wed Apr 04 13:53:55 2012, ikegami [at] adaelis wrote:
> > > The builtin "if" should expect the following to follow it (ignoring
> > > whitespace)
> > >
> > > "(" EXPR ")" BLOCK ( "elsif" "(" EXPR ")" BLOCK )* ( "else" BLOCK )?
> > >
> > > None of those tokens should be overridable when parsing that rule
> > (although
> > > EXPR and BLOCK may use overridden tokens).
> >
> > In that case, is there any reason why elsif needs to be a reserved word
> > outside of that context?
> >
>
> I was wondering that myself when I typed the above. We allow C<< sub
if { }
> >>, so why not C<< sub elsif { } >>?
>
> I'm not seeing the value of C<< elsif(); >> being a syntax error.

Allowing C<< sub elsif { } >> and having C<< elsif(); >> be a syntax
error by default are not exclusive.

The real question is: Without an imported override named elsif, what
should elsif(); do?

Another way of putting it: Should there by a sub named CORE::elsif that
produces a syntax error when inlined? Or should there be no CORE::elsif
sub at all, elsif only being treated as a keyword after if(){} or elsif{}?

I’m leaning toward the former right now, as it avoids changing the
behaviour unnecessarily.

> The two
> reasons I can come up for continuing to be a syntax error are confusion
> avoidance and syntax error detection, but neither reason is valid. We
> already allow C<< sub if { } >>, and C<< elsif (...) { ... } >> would
still
> be a syntax error if C<< elsif(...); >> isn't.

With custom call parsers, elsif(){} could be valid syntax even with a
sub named elsif :-).

--

Father Chrysostomos


perlbug-comment at perl

Apr 22, 2012, 2:43 PM

Post #3 of 21 (353 views)
Permalink
[perl #108286] Wishlist: Overridable keywords [In reply to]

On Sun Jan 15 12:51:08 2012, sprout wrote:
> I also propose that we add an :iter attribute, that will allow custom
> subs to get the special defined() treatment that glob and readline
> get inside a while() condition. (while(glob "foo") is equivalent
> to while(defined(glob "foo")).)

Actually, it’s equivalent to while(defined($_ = glob "foo")).

Interestingly, while($x=<foo>) did not get the special treatment until
commit 4b161ae29769, which I think was somewhere on the 5.004 maint branch.

Commit 4b161ae29769 also made while($x=each %foo) get wrapped in
defined(), but did not affect while(each %foo), which gets neither
defined() nor $_=.

Was $_= omitted to avoid backward-compatibility problems, or was it an
oversight? Was it simply an oversight that defined() was omitted in
that case?

The reason I ask is that it would be nice if we could make this all
consistent, but there may be good reasons why we cannot.

I also need to know how this will affect my :iter proposal. Based on
the precedent set by ‘each’, while($x=itersub) should become
while(defined($x=itersub)). But what should happen for while(itersub)?
Should it stay as it is (like each)? Should it become
while(defined($_=itersub)) like readline? Or should we take a middle
ground, and make it while(defined(itersub))?

Also, as long as ‘each’ follows its own rules, how is one to override it
with another iterator function, while preserving exactly the same syntax?

Maybe in the end we need to let the iter sub itself decide, and while()
could call it with a special param, or a package variable (like
$AUTOLOAD), or *somehow* signal it to tell it that it is in a while().

--

Father Chrysostomos


perlbug-followup at perl

Apr 23, 2012, 2:55 PM

Post #4 of 21 (358 views)
Permalink
[perl #108286] Wishlist: Overridable keywords [In reply to]

On Mon Apr 23 14:20:09 2012, dcmertens.perl [at] gmail wrote:
> Can someone point me to the discussion where it was decided that
overriding
> if() was a good idea? It seems to have sprung out of nowhere in this
> discussion. I skimmed through the related tickets but only saw discussion
> of glob(). Did I miss it?

Overriding if() and being *able* to override if() are two different things.

Anyone who overrides if() is probably asking for trouble.

But it would be nice to override length() and vec(). Where do we draw
the line? Or, rather, why do we need to draw a line? Instead of
debating over every keyword about whether it should be overridable,
let’s just make them all overridable, allowing smarter people to do
things we haven’t thought of.

I only brought up if() in particular because it can have elsif attached
to it, and we need to figure out how things are going to fit together.

--

Father Chrysostomos


---
via perlbug: queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=108286


perlbug-followup at perl

Apr 23, 2012, 3:13 PM

Post #5 of 21 (357 views)
Permalink
[perl #108286] Wishlist: Overridable keywords [In reply to]

On Mon Apr 23 14:03:27 2012, nicholas wrote:
> The intent of the changes appears to be to retain the 5.003 and
> earlier
> behaviour on what gets assigned for each construction, but change the
> loop
> behaviour to terminate on undefined rather than simply falsehood for
> the
> common simple cases:
>
> while (OP ...)
>
> and
>
> while ($var = OP ...)

Except that while($var = each %h) implies defined(), but while(each %h)
does not. So something got screwed up. :-)

--

Father Chrysostomos


---
via perlbug: queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=108286


perlbug-followup at perl

Apr 23, 2012, 3:19 PM

Post #6 of 21 (356 views)
Permalink
[perl #108286] Wishlist: Overridable keywords [In reply to]

Χριστὸς ἀνέστη!

On Mon Apr 23 03:03:36 2012, aristotle wrote:
> * Aristotle Pagaltzis <pagaltzis [at] gmx> [2012-04-23 12:01]:
> > The protocol with undef obviously makes sense for `each` as a hash key
> > can never be undef. But when iterating arbitrarily (e.g. converting an
> > array to an iter), undef becomes a valid value, no?
> >
> > So you cannot use it to abort iteration… unless you contrive something
> > contorted like returning a scalarref to the real value on every
> > successful iteration (thus turning undef in the data into \undef which
> > is true) and then an undef once you are done.
>
> Hmm. Now I am wondering how contrived that really is. I wonder if this
> could be baked into the protocol, i.e. an :iter function returning any
> value other than undef or a reference would throw an exception.
>
> Then unpacking a scalarref into $_ could be baked right into the `while`
> magic (returning other types of reference would be allowed but they
> would, obviously, not be automatically deref’d) and you could write
> Perlishly concise iterating loops at the price of a single backslash in
> your iterator functions.
>
> Warning: highly experimental. I am a long way from thinking through all
> the implications, the automatic deref in particular may turn out to be
> a terrible idea in practice.

This reference interface would make the sub practically unusable outside
of a while loop.

>
> But if the pieces come together then I would be eager to prototype this
> somewhere to see how well it holds up.

I’ve already been thinking about that. This would require hooking
PL_check or something to intercept how while loops are compiled. And
then, to work with closures, we would have to associate the attribute
with the address of the op tree. I can already see how that could be
accomplished, without memory leaks, using tied field hashes.

> If we could get a solid, supported iteration mechanism right into core
> that would *rock*.

But we may end up with too many variations that are all equally good,
but designed for different circumstances. Maybe in the end the core
docs could recommend Sub::Iter (or whatever name it gets), they way they
do Unicode::Casing.

--

Father Chrysostomos


---
via perlbug: queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=108286


perlbug-followup at perl

Apr 23, 2012, 3:21 PM

Post #7 of 21 (361 views)
Permalink
[perl #108286] Wishlist: Overridable keywords [In reply to]

On Mon Apr 23 15:19:09 2012, sprout wrote:
> I’ve already been thinking about that. This would require hooking
> PL_check or something to intercept how while loops are compiled. And
> then, to work with closures, we would have to associate the attribute
> with the address of the op tree. I can already see how that could be
> accomplished, without memory leaks, using tied field hashes.

In fact, in the process of thinking about this and considering where the
attribute could be stored, I’ve noticed that cv_clone doesn’t copy
magic, which means that call checkers added in attribute handlers won’t
apply to closures cloned therefrom. I think this is clearly a bug. But
(and this question is aimed mostly at Zefram) would copying the magic be
the best solution? Is there a standard way of copying magic already
that cv_clone can use?

--

Father Chrysostomos


---
via perlbug: queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=108286


perlbug-followup at perl

Apr 23, 2012, 6:11 PM

Post #8 of 21 (353 views)
Permalink
[perl #108286] Wishlist: Overridable keywords [In reply to]

On Mon Apr 23 15:19:09 2012, sprout wrote:
> And
> then, to work with closures, we would have to associate the attribute
> with the address of the op tree. I can already see how that could be
> accomplished, without memory leaks, using tied field hashes.

That’s assuming that the prototype is never freed before the closure
cloned from it.

Is that always the case?

As I understand it, the closure references the subroutine outside of it.
That subroutine’s op tree references the closure prototype. Is that right?


--

Father Chrysostomos


---
via perlbug: queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=108286


perlbug-followup at perl

Apr 23, 2012, 6:15 PM

Post #9 of 21 (360 views)
Permalink
[perl #108286] Wishlist: Overridable keywords [In reply to]

On Mon Apr 23 16:26:04 2012, LeonT wrote:
> On Tue, Apr 24, 2012 at 12:41 AM, Leon Timmermans <fawaka [at] gmail>
wrote:
> > That's what mg_copy is for, assuming the magic has a copy method
> > implemented (I think it doesn't).
>
> No, that's wrong. It's mg_dup. I hate how confusing those two names are.

I’ve just had a look at the code, and I see that mg_dup is defined only
under threads. So I don’t think it is what I want. And I think you
were right the first time. So, thank you.

What is the significance of the return value of mg_copy? It seems to be
the number of magic structs copied. But it is always called in void
context, at least in core.

--

Father Chrysostomos


---
via perlbug: queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=108286


perlbug-followup at perl

Apr 24, 2012, 8:56 AM

Post #10 of 21 (343 views)
Permalink
[perl #108286] Wishlist: Overridable keywords [In reply to]

On Tue Apr 24 01:10:59 2012, jv wrote:
> > Anyone who overrides if() is probably asking for trouble.
> > But it would be nice to override length() and vec(). Where do we draw
> > the line?
>
> Precisely <-- HERE.
> Functions like vec() and length() can be overridden, but control
> keywords like if and when and while can not.
>
> Writing it as if() doesn't make it similar to vec() or length().
>
> > Or, rather, why do we need to draw a line? Instead of debating over
> > every keyword about whether it should be overridable, ...
>
> Drawing a line means there's a vast group of keywords (functions) that
> can be overridden, a smaller group that can not, and maybe a few dubious
> cases that need discussion. Doesn't sounds that hard to me.

OK, so now we are debating about whether we should debate. :-)

How about ‘given’? I would love to be able to override it with
something that actually works, in which case I would need ‘when’ as well.

How about being able to override ‘if’ to make if(<>) dwim? How about
overriding ‘while’ to make a non-dwimmy do-what-I-say version? These,
of course, don’t have to be global overrides.

Do you realise that Perl has three distinct override methods and one of
them (PL_keyword_plugin) already allows ‘if’ to be overridden? Why
should the other two (use subs and CORE::GLOBAL) be left out?

>
> > ...let’s just make them all overridable, allowing smarter people to do
> > things we haven’t thought of.
>
> This would be okay if we can be 100% sure that changes like these do not
> introduce additional code complexity and other future maintenance
> problems. "Oh no, we cannot remove this because we have once said that
> it would be possible and maybe there's someone on earth actually using
> it".
>
> Let's be a bit careful.

I think about future backward-compatibility all the time. That’s why
&CORE::eof croaks with ‘&CORE::eof cannot be called directly’. It’s not
clear whether it should mean eof or eof() (the parentheses make a
difference). And picking one behaviour over the other will cause
backward-compatibility problems later if we invent a new way to express
that difference using prototypes.

I’ve been thinking carefully about the implications of overriding things
like ‘if’ and ‘for’. The fact is that they are already overridable,
though only via one overriding mechanism, so there is no possibility for
future compatibility problems, as long as the overridability via CVs is
limited to ‘use v5.16’ scopes.


@UNIVERSAL::ISA = CORE;
print $_->ucfirst for "just another ", "perl hacker,\n";

--

Father Chrysostomos


---
via perlbug: queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=108286


perlbug-followup at perl

Apr 24, 2012, 8:57 AM

Post #11 of 21 (344 views)
Permalink
[perl #108286] Wishlist: Overridable keywords [In reply to]

On Tue Apr 24 08:56:47 2012, sprout wrote:
> as long as the overridability via CVs is
> limited to ‘use v5.16’ scopes.

I mean v5.18/20/whatever.

--

Father Chrysostomos


---
via perlbug: queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=108286


perlbug-followup at perl

Apr 24, 2012, 12:57 PM

Post #12 of 21 (341 views)
Permalink
[perl #108286] Wishlist: Overridable keywords [In reply to]

On Tue Apr 24 11:59:36 2012, jv wrote:
> [Quoting Jesse Luehrs, on April 24 2012, 13:49, in "Re: [perl #108286] W"]
> > > I cannot imagine a sensible purpose to override else. Can you?
> >
> > No, I think that if() should be the overridable part, with 'else' and
> > 'elsif' just as much a part of the syntax as '{' or '}'.
>
> Precisely.

I’m having trouble understanding what you disagree with.

What I am proposing would allow

use subs "if";
sub if { ... }

plus magic attached to \&if via Devel::Declare or Devel::CallParser to
parse if/elsif/else however it wants, maybe even allowing elsunless.

>
> May I bring up a different but related topic?
>
> While writing Camel IV we noticed that several of the new features
> were very hard to document, because the implementation had been
> focused mainly on technical aspects and not on usability.

Could you give some examples?

> Are we
> learning from that experience?

Not without examples. :-)

> Or do we face the same disaster should
> we ever decide to write Camel V?

How was it a disaster?

--

Father Chrysostomos


---
via perlbug: queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=108286


perlbug-followup at perl

Apr 24, 2012, 1:01 PM

Post #13 of 21 (344 views)
Permalink
[perl #108286] Wishlist: Overridable keywords [In reply to]

On Tue Apr 24 11:40:43 2012, jv wrote:
> I cannot imagine a sensible purpose to override else. Can you?

No, but few could think of sensible reasons for wanting to write to $$,
so it was made read-only. Then some CPAN modules started using XS code
to turn off the read-only flag to make it writable again. Arbitrary
restrictions don’t help anyone.

--

Father Chrysostomos


---
via perlbug: queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=108286


perlbug-followup at perl

Apr 24, 2012, 1:03 PM

Post #14 of 21 (347 views)
Permalink
[perl #108286] Wishlist: Overridable keywords [In reply to]

On Tue Apr 24 09:07:28 2012, ikegami [at] adaelis wrote:
> PS - Something to test: What happens if one overrides C<elsif> using the
> keyword plugin? Does it break C<if>?

Probably. And that is probably part of the reason Zefram wants to
deprecate the keyword plugin. That he wants to deprecate it is part of
the reason I would like to make all keywords overridable.

--

Father Chrysostomos


---
via perlbug: queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=108286


perlbug-followup at perl

Apr 24, 2012, 1:26 PM

Post #15 of 21 (362 views)
Permalink
[perl #108286] Wishlist: Overridable keywords [In reply to]

On Tue Apr 24 13:16:11 2012, doy [at] tozt wrote:
> On Tue, Apr 24, 2012 at 12:57:12PM -0700, Father Chrysostomos via RT
> wrote:
> > On Tue Apr 24 11:59:36 2012, jv wrote:
> > > [Quoting Jesse Luehrs, on April 24 2012, 13:49, in "Re: [perl
> #108286] W"]
> > > > > I cannot imagine a sensible purpose to override else. Can you?
> > > >
> > > > No, I think that if() should be the overridable part, with
> 'else' and
> > > > 'elsif' just as much a part of the syntax as '{' or '}'.
> > >
> > > Precisely.
> >
> > I’m having trouble understanding what you disagree with.
> >
> > What I am proposing would allow
> >
> > use subs "if";
> > sub if { ... }
> >
> > plus magic attached to \&if via Devel::Declare or Devel::CallParser
> to
> > parse if/elsif/else however it wants, maybe even allowing elsunless.
>
> I have no issues with this. But if the \&if is responsible for parsing
> the entire if/elsif/else construct (which I think it should be), how
> does the idea of overriding elsif/else independently work at all?

You would only do that if you wanted to start a construct with elsif or
else.

--

Father Chrysostomos


---
via perlbug: queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=108286


perlbug-followup at perl

Apr 24, 2012, 8:44 PM

Post #16 of 21 (343 views)
Permalink
[perl #108286] Wishlist: Overridable keywords [In reply to]

On Tue Apr 24 13:47:41 2012, doy [at] tozt wrote:
> On Tue, Apr 24, 2012 at 01:26:21PM -0700, Father Chrysostomos via RT
wrote:
> > You would only do that if you wanted to start a construct with elsif or
> > else.
>
> That's reasonable, but I also don't see what it has to do with the
> current topic - as it stands now, elsif and else aren't actual keywords,
> they are just syntactic sugar that is parsed as part of an if statement.

Actually they are reserved words outside that context that cause syntax
errors.

> Why do they need explicit handling in the core any more than any other
> arbitrary keyword someone might write (class, gather, etc) requires?

Good question. Eric Brine said more or less the same thing. And I’m
beginning to agree.

I think confusion is arising because I just cannot understand Johan
Vromans’ objections. Maybe I’m just too dense.

--

Father Chrysostomos


---
via perlbug: queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=108286


perlbug-followup at perl

Apr 24, 2012, 8:45 PM

Post #17 of 21 (342 views)
Permalink
[perl #108286] Wishlist: Overridable keywords [In reply to]

On Tue Apr 24 00:39:50 2012, nicholas wrote:
> On Mon, Apr 23, 2012 at 03:13:39PM -0700, Father Chrysostomos via RT
wrote:
> > On Mon Apr 23 14:03:27 2012, nicholas wrote:
> > > The intent of the changes appears to be to retain the 5.003 and
> > > earlier
> > > behaviour on what gets assigned for each construction, but change the
> > > loop
> > > behaviour to terminate on undefined rather than simply falsehood for
> > > the
> > > common simple cases:
> > >
> > > while (OP ...)
> > >
> > > and
> > >
> > > while ($var = OP ...)
> >
> > Except that while($var = each %h) implies defined(), but while(each %h)
> > does not. So something got screwed up. :-)
>
> Yes. I *thought* that question was about while(each %h) [not] assigning to
> $_, but I missed the [not] using defined.
>
> Pretty sure that the intent was that the intent at the time was to
change it
> to use defined. And I'd guess that it was missed because it's not the same
> opcode structure.
>
> So that's a bug?

That’s what I was trying to ask. :-)


--

Father Chrysostomos


---
via perlbug: queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=108286


perlbug-followup at perl

Apr 25, 2012, 8:47 PM

Post #18 of 21 (339 views)
Permalink
[perl #108286] Wishlist: Overridable keywords [In reply to]

On Wed Apr 25 04:30:22 2012, aristotle wrote:
> * Father Chrysostomos via RT <perlbug-followup [at] perl> [2012-04-24
00:20]:
> > Χριστὸς ἀνέστη!

Ἀληθῶς ἀνέστη.

>
> > On Mon Apr 23 03:03:36 2012, aristotle wrote:
> > > * Aristotle Pagaltzis <pagaltzis [at] gmx> [2012-04-23 12:01]:
> > > > The protocol with undef obviously makes sense for `each` as a hash
> > > > key can never be undef. But when iterating arbitrarily (e.g.
> > > > converting an array to an iter), undef becomes a valid value, no?
> > > >
> > > > So you cannot use it to abort iteration… unless you contrive
> > > > something contorted like returning a scalarref to the real value
> > > > on every successful iteration (thus turning undef in the data into
> > > > \undef which is true) and then an undef once you are done.
> > >
> > > Hmm. Now I am wondering how contrived that really is. I wonder if
> > > this could be baked into the protocol, i.e. an :iter function
> > > returning any value other than undef or a reference would throw an
> > > exception.
> > >
> > > Then unpacking a scalarref into $_ could be baked right into the
> > > `while` magic (returning other types of reference would be allowed
> > > but they would, obviously, not be automatically deref’d) and you
> > > could write Perlishly concise iterating loops at the price of
> > > a single backslash in your iterator functions.
> > >
> > > Warning: highly experimental. I am a long way from thinking through
> > > all the implications, the automatic deref in particular may turn out
> > > to be a terrible idea in practice.
> >
> > This reference interface would make the sub practically unusable
> > outside of a while loop.
>
> “Practically unusable”, really? Is there a need for the hyperbole? :-)
>
> Take a more holistic perspective: an :iter in Perl is going to have
> a semi-predicate problem. Do you have a more usable strategy than my
> proposal to deal with that?
>
> I can only think of two other options – signaling exhaustion with an
> exception (brrrrr) or simply punting (pushing the complexity to the user
> end of the water bed, makes it nice and comfortable for the language
> designer for sleeping on his job :-) ). I think either of them is worse,
> in fact option 1 makes my teeth crawl.
>
> I certainly concede that having to deref scalars is not pretty, but a
>
> sub deref { ${$_[0]} }
>
> takes care of that for calling iterators manually, and consider how much
> the ref-only protocol buys you in the overall picture given the options.

We seem to be trying to solve two different problems. What I want to do
is allow an overridden readline to be treated the same way as
CORE::readline, without special-casing the name, but the sub itself.

If it starts having to return refs to work with while(), then it won’t
behave the same way as readline outside of a while().

I think disallowing undefs in mid-list is a reasonable trade-off. You,
apparently, do not think so. :-)

>
> > > If we could get a solid, supported iteration mechanism right into
> > > core that would *rock*.
> >
> > But we may end up with too many variations that are all equally good,
> > but designed for different circumstances. Maybe in the end the core
> > docs could recommend Sub::Iter (or whatever name it gets), they way
> > they do Unicode::Casing.
>
> Guhhh. I’m sure all the different string libraries in C++ are good too.
>
> I’m not against people building higher-level abstractions but it matters
> for the builtins to support iteration directly, and they have to pick
> a protocol for that. And that will provide a point of uniformity at
> which everything can interoperate. Just look at the enormous benefit
> PSGI brought to webdev in Perl by providing such a point of interop that
> higher-level frameworks.
>
> Importantly, this means making it easy to get the same interface from
> builtin data types, so that code can be written that easily works with
> both data structures and iterators.
>
> PSGI’s job in turn would have been enormously simplified by having such
> a facility available – which exists in Python and Ruby, where their
> respective web glue layers make good use of it. Instead for PSGI had to
> invent its own conventions for this and now middlewares have to be
> written to specifically support streaming by using callback-based
> utility functions provided by Plack. It’s all very warty.

Well, we can start with Sub::Iter (or whatever), point to it from the
core docs at least for a while. Later, when one variant of it proves
useful, *then* put it in core.

> (The coolest would be to add :iter support to `foreach` along the lines
> of `for my $i (1..1_000_000_000) {}` i.e. without inflating the entire
> range in memory first.)

Which sounds an awful lot like what while(my $i = each %foo) already
does, which would be covered by my proposal for while(my $i = iterfunc).
I.e., you can use while for that, rather than for.

--

Father Chrysostomos


---
via perlbug: queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=108286


perlbug-followup at perl

Apr 27, 2012, 1:35 PM

Post #19 of 21 (323 views)
Permalink
[perl #108286] Wishlist: Overridable keywords [In reply to]

On Sun Jan 15 12:51:08 2012, sprout wrote:
> Proposal
> --------

> glob overrides should no longer be passed a second argument. The only
> code using the undocumented second argument anywhere on CPAN is in
> the core and can be changed.

One instance in core is in File::DosGlob::glob. Is this ever used under
miniperl?

As far as I can tell, under miniperl CORE::glob runs ‘perlglob’. But I
don’t know whether that is win32/perlglob.c or win32/bin/perlglob.pl.
In any case, the latter only uses File::DosGlob::doglob, which is the
back end to File::DosGlob::glob.

So, it looks as though File::DosGlob::glob could start requiring XS, but
only loads it on demand, allowing doglob to work under miniperl,

Is there anything egregiously wrong with that? What have I missed?

--

Father Chrysostomos


---
via perlbug: queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=108286


perlbug-followup at perl

Apr 27, 2012, 2:00 PM

Post #20 of 21 (330 views)
Permalink
[perl #108286] Wishlist: Overridable keywords [In reply to]

On Fri Apr 27 13:35:48 2012, sprout wrote:
> On Sun Jan 15 12:51:08 2012, sprout wrote:
> > Proposal
> > --------
>
> > glob overrides should no longer be passed a second argument. The only
> > code using the undocumented second argument anywhere on CPAN is in
> > the core and can be changed.
>
> One instance in core is in File::DosGlob::glob. Is this ever used under
> miniperl?
>
> As far as I can tell, under miniperl CORE::glob runs ‘perlglob’.

I forgot to add ‘on Windows’.

> But I
> don’t know whether that is win32/perlglob.c or win32/bin/perlglob.pl.
> In any case, the latter only uses File::DosGlob::doglob, which is the
> back end to File::DosGlob::glob.
>
> So, it looks as though File::DosGlob::glob could start requiring XS, but
> only loads it on demand, allowing doglob to work under miniperl,
>
> Is there anything egregiously wrong with that? What have I missed?

If perlglob.pl/bat is used by CORE::glob under miniperl on Windows, then
ext/File-DosGlob/lib would have to be added to miniperl’s default path.

But this rule in win32/Makefile suggests that perlglob.exe is what is
used for minitest:

minitest : $(MINIPERL) $(GLOBEXE) $(CONFIGPM) utils $(UNIDATAFILES)
$(XCOPY) $(MINIPERL) ..\t\$(NULL)
if exist ..\t\perl.exe del /f ..\t\perl.exe
rename ..\t\miniperl.exe perl.exe
$(XCOPY) $(GLOBEXE) ..\t\$(NULL)
attrib -r ..\t\*.*
cd ..\t && \
$(MINIPERL) -I..\lib harness base/*.t comp/*.t cmd/*.t io/*.t op/*.t
pragma/*.t

$(GLOBEXE) is built like this:

$(GLOBEXE) : perlglob$(o)
$(LINK32) $(LINK_FLAGS) $(LIBFILES) -out:$@ -subsystem:$(SUBSYS) \
perlglob$(o) setargv$(o)
$(EMBED_EXE_MANI)

So I think File::DosGlob is indeed unused by miniperl.

--

Father Chrysostomos


---
via perlbug: queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=108286


perlbug-followup at perl

Apr 28, 2012, 12:41 AM

Post #21 of 21 (327 views)
Permalink
[perl #108286] Wishlist: Overridable keywords [In reply to]

On Sun Jan 15 12:51:08 2012, sprout wrote:
> The keywords do, require and glob are currently not overridable as
> keywords. Overrides cannot change their syntax, but only their
> behaviour. In other words, overrides of these keywords are
> actually callbacks, rather than overrides.
>
> I propose that whether overrides of those three keywords are actual
> keyword overrides depend on whether the ‘overrides’ feature is
> enabled in the scope where the subroutine is defined, not where it
> is used.

This poses a slight problem in the default case (outside the scope of
the overrides feature).

If require is always a keyword (and it is, because the prototype cannot
be overridden), then we have a keyword that behaves differently
depending on whether there is a CORE:: prefix.

So, which behaviour should \&CORE::require have? It should probably be
the same as CORE::require. And require’s fixed prototype should be
treated as a special case.

I was trying to come up with a model that would encompass all special
cases, such that there wouldn’t be any special cases any more (they all
being CV-specific parsing rules), but I have failed in this particular case.

Does anyone else (particularly Zefram, since a lot of this is based on
his ideas) have ideas?

--

Father Chrysostomos


---
via perlbug: queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=108286

Perl porters RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.