perlbug-followup at perl
Apr 25, 2012, 8:47 PM
Post #18 of 21
(216 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
|
