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

Mailing List Archive: Perl: porters

[perl #108286] Wishlist: Overridable keywords

 

 

First page Previous page 1 2 3 Next page Last page  View All Perl porters RSS feed   Index | Next | Previous | View Threaded


doy at tozt

Apr 24, 2012, 11:18 AM

Post #26 of 55 (417 views)
Permalink
Re: [perl #108286] Wishlist: Overridable keywords [In reply to]

On Tue, Apr 24, 2012 at 08:05:21PM +0200, Johan Vromans wrote:
> Jesse Luehrs <doy [at] tozt> writes:
>
> > What about
> > overriding something like map? The distinction isn't quite as clear as
> > you seem to be implying.
>
> Despite its weird syntax, map is just a function. No problem overriding.
>
> But above all lies the question: what for?
>
> We know we *can* do it. I suggest not to do it. Okay, throw away the
> distinction between if and other keywords, np, but add a fatal error if
> someone tries to override if and friends.
>
> Now, if someone can come up with a real good reason why overriding if
> would be beneficial to the Perl community, *then* remove the error
> message.

I have on occasion wished for a more functional programming-style if
statement:

my $foo = if ($foo->bar) { $bar } else { $baz };

It is a lot more readable than ?: when the expressions get more
complicated.

Looking at it from the other side, I really don't understand what making
an arbitrary distinction between keywords that are allowed to be
overridden and keywords that aren't allowed to be overridden actually
gains us. That is just extra arbitrary restrictions that have to be
remembered, which just adds complication. Why do you think this makes
anything simpler?

-doy


jvromans at squirrel

Apr 24, 2012, 11:24 AM

Post #27 of 55 (418 views)
Permalink
Re: [perl #108286] Wishlist: Overridable keywords [In reply to]

"Father Chrysostomos via RT" <perlbug-followup [at] perl> writes:

> 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.

My first reaction to this thread was: override okay, but then as a set
of keywords. if, else and elsif go together. given, when etc likewise.

I can easily imagine a pragma that changes the behaviour of such a set
of keywords.

But just overriding keywords like if independently... Yuck.

BTW, for the if(<>) dwim, I'd consider overriding the readline function
instead.

-- Johan


jvromans at squirrel

Apr 24, 2012, 11:39 AM

Post #28 of 55 (418 views)
Permalink
Re: [perl #108286] Wishlist: Overridable keywords [In reply to]

[Quoting Jesse Luehrs, on April 24 2012, 13:18, in "Re: [perl #108286] W"]
> I have on occasion wished for a more functional programming-style if
> statement:
>
> my $foo = if ($foo->bar) { $bar } else { $baz };
>
> It is a lot more readable than ?: when the expressions get more
> complicated.

I definitely agree.

> Looking at it from the other side, I really don't understand what
> making an arbitrary distinction between keywords that are allowed to
> be overridden and keywords that aren't allowed to be overridden
> actually gains us. That is just extra arbitrary restrictions that
> have to be remembered, which just adds complication. Why do you
> think this makes anything simpler?

Because, as was remarked earlier in this thread, overriding if() is
asking for trouble.

But again -- overriding if, else and elsif as a whole (cf. tie) would
be feasible. Bot not as loose keywords.

I cannot imagine a sensible purpose to override else. Can you?

-- Johan


doy at tozt

Apr 24, 2012, 11:49 AM

Post #29 of 55 (421 views)
Permalink
Re: [perl #108286] Wishlist: Overridable keywords [In reply to]

On Tue, Apr 24, 2012 at 08:39:54PM +0200, Johan Vromans wrote:
> [Quoting Jesse Luehrs, on April 24 2012, 13:18, in "Re: [perl #108286] W"]
> > I have on occasion wished for a more functional programming-style if
> > statement:
> >
> > my $foo = if ($foo->bar) { $bar } else { $baz };
> >
> > It is a lot more readable than ?: when the expressions get more
> > complicated.
>
> I definitely agree.
>
> > Looking at it from the other side, I really don't understand what
> > making an arbitrary distinction between keywords that are allowed to
> > be overridden and keywords that aren't allowed to be overridden
> > actually gains us. That is just extra arbitrary restrictions that
> > have to be remembered, which just adds complication. Why do you
> > think this makes anything simpler?
>
> Because, as was remarked earlier in this thread, overriding if() is
> asking for trouble.
>
> But again -- overriding if, else and elsif as a whole (cf. tie) would
> be feasible. Bot not as loose keywords.
>
> 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 '}'.

-doy


doy at tozt

Apr 24, 2012, 11:51 AM

Post #30 of 55 (418 views)
Permalink
Re: [perl #108286] Wishlist: Overridable keywords [In reply to]

On Tue, Apr 24, 2012 at 08:24:40PM +0200, Johan Vromans wrote:
> "Father Chrysostomos via RT" <perlbug-followup [at] perl> writes:
>
> > 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.
>
> My first reaction to this thread was: override okay, but then as a set
> of keywords. if, else and elsif go together. given, when etc likewise.
>
> I can easily imagine a pragma that changes the behaviour of such a set
> of keywords.
>
> But just overriding keywords like if independently... Yuck.
>
> BTW, for the if(<>) dwim, I'd consider overriding the readline function
> instead.

given/when are actually independent keywords - they are actually more
like for/next/last/etc. (whether this is actually a good idea is
debatable, but that is how they work currently). Overriding elsif
outside of the context of if() doesn't actually make any sense - elsif
isn't (or shouldn't be, anyway) a keyword on its own, it is just a token
that is an expected part of parsing an if statement.

-doy


jvromans at squirrel

Apr 24, 2012, 11:59 AM

Post #31 of 55 (419 views)
Permalink
Re: [perl #108286] Wishlist: Overridable keywords [In reply to]

[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.

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. Are we
learning from that experience? Or do we face the same disaster should
we ever decide to write Camel V?

-- Johan


doy at tozt

Apr 24, 2012, 1:15 PM

Post #32 of 55 (420 views)
Permalink
Re: [perl #108286] Wishlist: Overridable keywords [In reply to]

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?

-doy


doy at tozt

Apr 24, 2012, 1:47 PM

Post #33 of 55 (422 views)
Permalink
Re: [perl #108286] Wishlist: Overridable keywords [In reply to]

On Tue, Apr 24, 2012 at 01:26:21PM -0700, Father Chrysostomos via RT wrote:
> 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.

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.
Why do they need explicit handling in the core any more than any other
arbitrary keyword someone might write (class, gather, etc) requires?

-doy


jvromans at squirrel

Apr 24, 2012, 11:30 PM

Post #34 of 55 (420 views)
Permalink
Re: [perl #108286] Wishlist: Overridable keywords [In reply to]

> [Quoting Jesse Luehrs, on April 24 2012, 13:18, in "Re: [perl #108286] W"]
>> I have on occasion wished for a more functional programming-style if
>> statement:
>>
>> my $foo = if ($foo->bar) { $bar } else { $baz };
>>
>> It is a lot more readable than ?: when the expressions get more
>> complicated.

So if you want to improve Perl, why not implement this?
Seems more useful than being able to redefine if() ...

-- Johan


doy at tozt

Apr 24, 2012, 11:32 PM

Post #35 of 55 (422 views)
Permalink
Re: [perl #108286] Wishlist: Overridable keywords [In reply to]

On Wed, Apr 25, 2012 at 08:30:29AM +0200, Johan Vromans wrote:
> > [Quoting Jesse Luehrs, on April 24 2012, 13:18, in "Re: [perl #108286] W"]
> >> I have on occasion wished for a more functional programming-style if
> >> statement:
> >>
> >> my $foo = if ($foo->bar) { $bar } else { $baz };
> >>
> >> It is a lot more readable than ?: when the expressions get more
> >> complicated.
>
> So if you want to improve Perl, why not implement this?
> Seems more useful than being able to redefine if() ...

Because I think that being able to prototype things like this on CPAN
rather than in core is an excellent way to avoid things like the mess
that was given/when.

-doy


davidnicol at gmail

Apr 25, 2012, 12:50 AM

Post #36 of 55 (422 views)
Permalink
Re: [perl #108286] Wishlist: Overridable keywords [In reply to]

On Wed, Apr 4, 2012 at 3:28 PM, John Imrie <j.imrie1 [at] virginmedia> wrote:
>
> On 04/04/2012 19:58, Johan Vromans wrote:
>>
>> "Father Chrysostomos via RT"<perlbug-comment [at] perl>  writes:
>>
>>> But there is one thing my plans did not address:  How should elsif and
>>> else work?  If elsif is overridable like any other keyword, then what
>>> happens in cases like this?
>>
>> Suggestion: Do not allow if, else, elseif to be overridden independently
>> but treat them as one set of keywords.
>>
>> So you either override them all, or none.
>>
>> Does that make sense?
>>
>> -- Johan
>
> Opposing suggestion:
> Allow overriding of if, else and elsif to be overridden independently but make
>
> CORE::KEYWORD::if etc. have the default semantics.
>
> John

Opposing opposing and very possibly insane suggestion:
redefine all keywords as overridable macros, thereby trading endless
but unified drift for a profusion of local incompatible dialects.

This could be called the "babel strawman" and it is an argument
against allowing *any* flow control syntax to be overridden.



--
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted using situational ethics.


davidnicol at gmail

Apr 25, 2012, 12:58 AM

Post #37 of 55 (420 views)
Permalink
Re: [perl #108286] Wishlist: Overridable keywords [In reply to]

On Tue, Apr 24, 2012 at 1:18 PM, Jesse Luehrs <doy [at] tozt> wrote:

> I have on occasion wished for a more functional programming-style if
> statement:
>
>  my $foo = if ($foo->bar) { $bar } else { $baz };
>
> It is a lot more readable than ?: when the expressions get more
> complicated.

C<do> is very handy and will let you do that:

$ perl -le 'my $X = do { if ( 0 ) { 27 } else { 33 }};print $X'
33

$ perl -le 'my $X = do { if ( 1 ) { 27 } else { 33 }};print $X'
27

--
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" are to be interpreted using situational ethics.


pagaltzis at gmx

Apr 25, 2012, 4:29 AM

Post #38 of 55 (420 views)
Permalink
Re: [perl #108286] Wishlist: Overridable keywords [In reply to]

* 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.

> > 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.

(Of course, let a thousand abstractions bloom on top of the :iter
protocol. That is not what I am arguing against. What I argue is that
core should provide a point of interop between them all, much like PSGI
provides a point of interop between web frameworks. Let a thousand web
frameworks bloom after that. (And oh god have they ever.))

(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.)

Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>


jvromans at squirrel

Apr 25, 2012, 1:20 PM

Post #39 of 55 (425 views)
Permalink
Re: [perl #108286] Wishlist: Overridable keywords [In reply to]

David Nicol <davidnicol [at] gmail> writes:

> C<do> is very handy and will let you do that:

As will C<eval>.

Okay, I must admit it is 2 characters longer.

-- Johan


demerphq at gmail

Apr 25, 2012, 1:22 PM

Post #40 of 55 (422 views)
Permalink
Re: [perl #108286] Wishlist: Overridable keywords [In reply to]

On 25 April 2012 22:20, Johan Vromans <jvromans [at] squirrel> wrote:
> David Nicol <davidnicol [at] gmail> writes:
>
>> C<do> is very handy and will let you do that:
>
> As will C<eval>.
>
> Okay, I must admit it is 2 characters longer.

And probably slower. :-)

Yves


--
perl -Mre=debug -e "/just|another|perl|hacker/"


doy at tozt

Apr 25, 2012, 1:34 PM

Post #41 of 55 (420 views)
Permalink
Re: [perl #108286] Wishlist: Overridable keywords [In reply to]

On Wed, Apr 25, 2012 at 02:58:07AM -0500, David Nicol wrote:
> On Tue, Apr 24, 2012 at 1:18 PM, Jesse Luehrs <doy [at] tozt> wrote:
>
> > I have on occasion wished for a more functional programming-style if
> > statement:
> >
> > my $foo = if ($foo->bar) { $bar } else { $baz };
> >
> > It is a lot more readable than ?: when the expressions get more
> > complicated.
>
> C<do> is very handy and will let you do that:
>
> $ perl -le 'my $X = do { if ( 0 ) { 27 } else { 33 }};print $X'
> 33
>
> $ perl -le 'my $X = do { if ( 1 ) { 27 } else { 33 }};print $X'
> 27

Sure, but if I didn't care about it being pretty, ?: already works too(:

-doy


ikegami at adaelis

Apr 25, 2012, 3:09 PM

Post #42 of 55 (421 views)
Permalink
Re: [perl #108286] Wishlist: Overridable keywords [In reply to]

On Tue, Apr 24, 2012 at 4:03 PM, Father Chrysostomos via RT <
perlbug-followup [at] perl> wrote:

> 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.


I have confirmed that the keyword plugin is called when "if" fetches
"elsif".


> 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.
>

What is it we're suppose to use instead? Devel::Declare?

- Eric


doy at tozt

Apr 25, 2012, 3:18 PM

Post #43 of 55 (419 views)
Permalink
Re: [perl #108286] Wishlist: Overridable keywords [In reply to]

On Wed, Apr 25, 2012 at 06:09:59PM -0400, Eric Brine wrote:
> On Tue, Apr 24, 2012 at 4:03 PM, Father Chrysostomos via RT <
> perlbug-followup [at] perl> wrote:
> > 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.
> >
>
> What is it we're suppose to use instead? Devel::Declare?

Devel::CallParser/Devel::CallChecker. Devel::CallParser has already been
migrated to the core (as cv_set_call_checker), and a corresponding
cv_set_call_parser will likely be added to the core once the API has
been finalized.

-doy


davidnicol at gmail

Apr 26, 2012, 1:19 AM

Post #44 of 55 (422 views)
Permalink
Re: [perl #108286] Wishlist: Overridable keywords [In reply to]

On Wed, Apr 25, 2012 at 10:47 PM, Father Chrysostomos via RT
<perlbug-followup [at] perl> wrote:

>> Take a more holistic perspective: an :iter in Perl is going to have
>> a semi-predicate problem.

Only if the :iter interface is restricted to a single return value. An
:iter interface that required (initialize, test, increment) hooks for
a conformant keyword, however that happens, would no longer have the
http://en.wikipedia.org/wiki/Semipredicate_problem
because the completion notice would not be in the same channel as the data.

More work behind the scenes is the price of ease of use.


pagaltzis at gmx

Apr 29, 2012, 3:15 AM

Post #45 of 55 (419 views)
Permalink
Re: [perl #108286] Wishlist: Overridable keywords [In reply to]

* Jesse Luehrs <doy [at] tozt> [2012-04-24 20:20]:
> I have on occasion wished for a more functional programming-style if
> statement:
>
> my $foo = if ($foo->bar) { $bar } else { $baz };
>
> It is a lot more readable than ?: when the expressions get more
> complicated.

Can you show an actual such example? I have been looking for one or
trying to think of one but so far I come up empty. I am interested
to see what one would look like. In particular, while it may be more
readable than a ternary, how does it measure up against *other* ways
of expressing the same intent?

Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>


nick at ccl4

May 10, 2012, 7:47 AM

Post #46 of 55 (379 views)
Permalink
Re: [perl #108286] Wishlist: Overridable keywords [In reply to]

On Tue, Apr 24, 2012 at 08:45:32PM -0700, Father Chrysostomos via RT wrote:
> 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.

Right. So history isn't quite what I thought it was.

while (<STDIN>)
while (<*>)

These both always implicitly assigned to $_, always implicitly added defined.

while ($_ = <STDIN>)
while ($a = <STDIN>)
while ($_ = <*>)
while ($a = <*>)
while ($_ = readdir D)
while ($a = readdir D)
while ($_ = each %h)
while ($a = each %h)

The implicit defined added was by commit 4b161ae29769b4a3,
//depot/maint-5.004/perl [at] 94


BUT:

while (readdir D)

The implicit assignment to $_ and defined test were both added in *2009*
(by commit 114c60ecb1f7)


leaving:

while (each %h)


So it is the odd one out. And in 2009 we felt comfortable to add both the
implicit assignment and the defined test in blead for readdir, as a bug fix,
and have had no reports of it causing problems.

> > So that's a bug?
>
> That's what I was trying to ask. :-)

OK, after a quite a bit of deliberation and digging, I'm of the opinion that

1: yes, it's a bug

So, what on CPAN would be affected?

$ csearch 'while\s*\(\s*each'
/scratch/cpan/CSS-Inliner/t/ordering.t:while ( each %{$css} ) {$shuffle2++;}

This actually just seems to be counting the number of entries in the hash,
despite the comments:

#shuffle stored styles around
my $shuffle1 = 0;
foreach (keys %{$css}) { $shuffle1++;}

#shuffle stored styles around more
my $shuffle2 = 0;
while ( each %{$css} ) {$shuffle2++;}


/scratch/cpan/Games-Go-Player/lib/Games/Go/Player.pm: while (each %{$self->{$patternhash}}) {

(Inefficiently) counting the hash entries, in the debugging method tiestats():

while (each %{$self->{$patternhash}}) {
$count++;
}


/scratch/cpan/Geo-Ellipsoid/lib/Geo/Ellipsoid.pm: while( each %distance ) {}

# finish iterating to reset 'each' function call
while( each %distance ) {}

so, doesn't have any immediate side effects from also changing $_
(And could be more efficiently written)

/scratch/cpan/Math-NumSeq/lib/Math/NumSeq/JugglerSteps.pm: # while (each %cache) {

(Inefficiently) counting the hash entries, in debugging code:

# ### cache diagnostics ...
# my $count = 0;
# while (each %cache) {
# $count++;
# }

It's not really commented out code, as it's intended to be enabled by
using Devel::Comments - https://metacpan.org/module/Devel::Comments


/scratch/cpan/Noid/lib/Noid.pm:# $key = 0; while (each($noid, $key, $value)) { ... }

Typo in the documentation, should be eachnoid(...)

/scratch/cpan/Regexp-Fields/t/03-hash.t:while (each %{&}) { $count++ }

Quite intentionally testing the iterator:

"xyz" =~ /$rx/;
while (each %{&}) { $count++ }

is $count, 2, 'new match doesn\'t reset the iterator';

Documentation:

/scratch/cpan/SimpleCDB/SimpleCDB.pm:while (each %h) always shows as much data as you put in :-)


So, there's only one use of while(each %...) on CPAN outside of debugging or
test code, and that's only go the potential to break due to assignment now
happening to to $_. Compared with 29 matches for while\s*\(\s*readdir
of which 4 are .pm files. So

2: I think it's safe to fix it, just like readdir was fixed.

Nicholas Clark


ikegami at adaelis

May 15, 2012, 9:55 AM

Post #47 of 55 (377 views)
Permalink
Re: [perl #108286] Wishlist: Overridable keywords [In reply to]

On Tue, May 15, 2012 at 1:06 AM, Father Chrysostomos via RT <
perlbug-followup [at] perl> wrote:

> Given an mistake as easy to make as this:
>
> if($foo) { };
> else { $bar }
>
> do you think it is acceptable for
>
> syntax error at - line 2, near "else"
> Execution of - aborted due to compilation errors.
>
> to become
>
> Can't call method "else" on an undefined value at - line 2.
>
> ?
>
> Maybe it is.
>

ARGH! Indirect method call syntax bites again. Endless source of poor error
messages. How I hate thee.

The alternative is for "else" to remain a reserved word instead of a
keyword. Your prior questions indicate this would make things a bit messier
than ideal, but that's about all. You know better whether that's acceptable
or not.

- Eric


zefram at fysh

May 20, 2012, 4:40 AM

Post #48 of 55 (365 views)
Permalink
Re: [perl #108286] Wishlist: Overridable keywords [In reply to]

Eric Brine wrote:
>PS - Something to test: What happens if one overrides C<elsif> using the
>keyword plugin? Does it break C<if>?

I think the best way to do this (in the long run) is that the code to
parse the "if" syntax (which is magically attached to &if), when it sees
an identifier in a place that might be an "else" or "elsif", uses the
normal sub name lookup mechanism to decide what it means. Having resolved
the identifier to a sub ref, it checks whether this matches the &else or
&elsif that it knows about, and acts accordingly. &elsif is, of course,
a dummy sub, with parser magic that will just signal an error, because
"elsif" isn't allowed to be used on its own. The result is that you can
change the spelling of "elsif" by doing things like "*orif = \&elsif".
A user-added "if"-alike can use exactly the same mechanism, using either
the standard &elsif or its own dummy subs.

-zefram


zefram at fysh

May 20, 2012, 4:59 AM

Post #49 of 55 (366 views)
Permalink
Re: [perl #108286] Wishlist: Overridable keywords [In reply to]

Eric Brine wrote:
>What is it we're suppose to use instead? Devel::Declare?

The intention is to migrate Devel::CallParser into the core. I'm actually
in the middle of that, on hold due to the freeze for 5.16. I got the
mechanism working in the core, but then discovered that one of the
standard procedural argument parsers doesn't actually match the core
yacc parser. So want to fix that before putting it into blead. Once D:CP
is in the core, the PL_keyword_plugin will be obsolete and can be removed.

Generally, the paradigm I'm aiming for is to merge the keyword namespace
with the subroutine namespace, and have special parsing and compilation
behaviour implemented as magic attached to (possibly dummy) subroutines.
What sprout is addressing in this thread is the issue of making
existing builtins play relatively nicely with subroutine definitions.
That's an issue because currently builtins are a separate namespace
from subroutines, looked up in different ways. The aim is to make
user-supplied keywords as interchangeable with builtins as possible.

The PL_keyword_plugin mechanism, to the extent that it supplies any
namespace behaviour at all, goes with that older concept of keywords
being a different class of entity from subroutines. That turns out to be
awfully messy, because it requires the building of a separate mechanism
to manage the keyword namespace, where previously that wasn't an issue
because the keyword set was immutable. That's the motivation for reusing
the namespace mechanism that we've already got.

I've been putting off reading this thread for ages, sorry. Originally I
only read the first couple of messages, and then decided I needed to cool
off and then read it again to be sure of comprehending it correctly.
Initial thought is that I want us to explore multiple options for how
to make the namespaces work together. Sprout seems to have picked one
(very simple) way that they could work, and then bent everything else
to fit around it. I've got other ideas that may avoid the need for an
explicit feature flag.

-zefram


zefram at fysh

May 20, 2012, 5:08 AM

Post #50 of 55 (364 views)
Permalink
Re: [perl #108286] Wishlist: Overridable keywords [In reply to]

Father Chrysostomos via RT wrote:
>If require is always a keyword

I am troubled by the implications of this sort of condition. What does
it mean to be a keyword? What is the alternative to it being a keyword?
I'm aiming for a system where the things that have historically
been builtin keywords are processed as mere names of subroutines,
and there's no strong distinction between keyword-like entities and
compile-time-resolved subroutines. If you end up needing to make such
a distinction then something's gone wrong.

>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.

If you have a sub ref \&CORE::require, it must behave as a pure subroutine
at runtime. If you call through the ref, you are calling a sub, and
there is no opportunity for its prototype or other compile-time magic
to affect the call. By contrast, if you refer to it without sigil, in a
compile-time-resolvable manner, then its prototype and other magic should
take full effect at compile time, regardless of exactly what name you
used to refer to it. In the case of require, the special interpretation
of barewords is part of that compile-time magic.

>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.

Where exactly does the problem arise? I see no categorical problem with
doing this for require.

-zefram

First page Previous page 1 2 3 Next page Last page  View All 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.