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


perlbug-followup at perl

Jan 15, 2012, 12:51 PM

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

# New Ticket Created by Father Chrysostomos
# Please include the string: [perl #108286]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=108286 >


This touches on issues in tickets #84690, #94480, #96116, #105924, #105926 and #105928.

I have been thinking about this from time to time, and I think I finally have all the edge cases worked out:

Proposal
--------

I propose that we make ‘use feature "overrides"’ allow all keywords to be overridden.

Infix operators like ‘and’ will continue to be overridable only in non-infix positions. I.e., ‘use subs "and"; sub and () {} and and and’ will continue to parse as ‘&and && &and’, as it currently does. Allowing overridable infix operators would be nice, but is not part of this proposal. Maybe that can come later.

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. For XS functions, I don’t know which way we should do it. We probably need a new XS keyword, similar to PROTOTYPE.

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

All special-casing for parsing require VERSION should be removed from the tokenizer. ck_require can flag the op if it has a single unfolded numeric or vstring constant for its kidop. require VERSION should not delegate to a callback (‘override’) any more.

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.

<> should continue to call glob and readline overrides automatically.

Reasoning
---------

This should be in a feature feature, because otherwise the existence of a length method will cause every subsequent use of length() in the same file to produce a warning.

do, glob, and require should be overridable based on the hints where the sub is defined, not where the sub is used, because otherwise this would violate existing subs’ expectations. Existing require subs expect to receive "Foo/Bar.pm" rather than "Foo::Bar". A true override (with a * prototype) would leave it as "Foo::Bar". Similarly for glob overrides: an existing custom glob function might expect the automatic defined() in while(glob()).

The purpose of the :iter attribute is to avoid adding too many more hacks to fix bug #84690. It also allows true glob overrides to retain that feature.

Parsing of require VERSION is currently very screwy. It is not even consistent with itself. require also has the num/str bug, in that it tries to decide based on the type of its operand whether it will be a version number or a file name. We cannot fix that bug unless we make require VERSION a *syntactic* special case. In that case require $version would no longer work (thank goodness!). That means that require overrides would no longer be able to do CORE::require($_[0]), unless we stop calling the override in the case of a version number. That would apply only to ‘callback-style’ overrides; i.e., the old kind. require overrides defined under ‘use feature "overrides"’ would be true overrides which would not go through the special parsing at all, but would be required (i.e., allowed) to implement it themselves, if at all.

My reason for putting require parsing in this ticket is that it is inextricably linked to the overrides feature. It’s hard to change one without the other.

The reason for eliminating the second argument to glob() (did you even know about it?) is that <> will continue to call glob overrides, and glob implementations that want to accept lists will still be expected to handle <>’s calling convention.

---
Flags:
category=wishlist
severity=low
---
Site configuration information for perl 5.15.6:

Configured by sprout at Sat Dec 31 10:12:16 PST 2011.

Summary of my perl5 (revision 5 version 15 subversion 6) configuration:
Local Commit: b2635083831c8935c437465bbeb03aec8b599c01
Ancestor: 407287f90891c4292ac8268e6566164f3992e28e
Platform:
osname=darwin, osvers=10.5.0, archname=darwin-thread-multi-2level
uname='darwin pint.local 10.5.0 darwin kernel version 10.5.0: fri nov 5 23:20:39 pdt 2010; root:xnu-1504.9.17~1release_i386 i386 '
config_args='-de -Dusedevel -Duseithreads -DDEBUGGING -Dmad'
hint=recommended, useposix=true, d_sigaction=define
useithreads=define, usemultiplicity=define
useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
use64bitint=undef, use64bitall=undef, uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-fno-common -DPERL_DARWIN -DDEBUGGING -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include',
optimize='-O3 -g',
cppflags='-fno-common -DPERL_DARWIN -DDEBUGGING -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
ccversion='', gccversion='4.2.1 (Apple Inc. build 5664)', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
alignbytes=8, prototype=define
Linker and Libraries:
ld='env MACOSX_DEPLOYMENT_TARGET=10.3 cc', ldflags =' -fstack-protector -L/usr/local/lib'
libpth=/usr/local/lib /usr/lib
libs=-ldbm -ldl -lm -lutil -lc
perllibs=-ldl -lm -lutil -lc
libc=, so=dylib, useshrplib=false, libperl=libperl.a
gnulibc_version=''
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' '
cccdlflags=' ', lddlflags=' -bundle -undefined dynamic_lookup -L/usr/local/lib -fstack-protector'

Locally applied patches:


---
@INC for perl 5.15.6:
/usr/local/lib/perl5/site_perl/5.15.6/darwin-thread-multi-2level
/usr/local/lib/perl5/site_perl/5.15.6
/usr/local/lib/perl5/5.15.6/darwin-thread-multi-2level
/usr/local/lib/perl5/5.15.6
/usr/local/lib/perl5/site_perl
.

---
Environment for perl 5.15.6:
DYLD_LIBRARY_PATH (unset)
HOME=/Users/sprout
LANG=en_US.UTF-8
LANGUAGE (unset)
LD_LIBRARY_PATH (unset)
LOGDIR (unset)
PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin:/usr/local/bin
PERL_BADLANG (unset)
SHELL=/bin/bash


jvromans at squirrel

Jan 16, 2012, 10:35 AM

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

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

> I propose that we make ‘use feature "overrides"’ allow all keywords to
> be overridden.

I'll bite... I think it's a good plan.

-- Johan


perlbug-comment at perl

Jan 16, 2012, 1:28 PM

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

On Mon Jan 16 10:35:58 2012, jv wrote:
> Father Chrysostomos (via RT) <perlbug-followup [at] perl> writes:
>
> > I propose that we make ‘use feature "overrides"’ allow all keywords to
> > be overridden.
>
> I'll bite... I think it's a good plan.

I plan to implement it for 5.18.

--

Father Chrysostomos


perl.p5p at rjbs

Jan 23, 2012, 6:56 PM

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

* Father Chrysostomos via RT <perlbug-comment [at] perl> [2012-01-16T16:28:49]
>
> I plan to implement it for 5.18.

I look forward to thinking more about it and poking at your work :)

--
rjbs


jvromans at squirrel

Apr 4, 2012, 11:58 AM

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

"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


j.imrie1 at virginmedia

Apr 4, 2012, 1:28 PM

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

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


ikegami at adaelis

Apr 4, 2012, 1:47 PM

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

On Sun, Jan 15, 2012 at 3:51 PM, Father Chrysostomos <
perlbug-followup [at] perl> wrote:

> # New Ticket Created by Father Chrysostomos
> # Please include the string: [perl #108286]
> # in the subject line of all future correspondence about this issue.
> # <URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=108286 >
>
>
> This touches on issues in tickets #84690, #94480, #96116, #105924, #105926
> and #105928.
>
> I have been thinking about this from time to time, and I think I finally
> have all the edge cases worked out:
>
> Proposal
> --------
>
> I propose that we make use feature "overrides" allow all keywords to be
> overridden.
>

What do you mean by overriding a keyword? Do you mean a Perl-accessible
version of PL_keyword_plugin (i.e. the keyword introduces your own grammar
rule)? Do you mean the ability to pass them to "use subs"?


ikegami at adaelis

Apr 4, 2012, 1:53 PM

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

On Wed, Apr 4, 2012 at 11:50 AM, Father Chrysostomos via RT <
perlbug-comment [at] perl> wrote:

> 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?
>
> use feature 'overrides';
> use subs 'else';
> sub else(&) { die }
> if ($x) { }
> else { }
>

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

If by overriding a keyword you mean altering its syntax to something of the
user's choice, and if you want to change "else"'s syntax, override "if" and
"unless".

If by overriding a keyword you mean giving the ability to create functions
with the same name, and if you want create a sub called "else", the sub
call can be disambiguated with a leading ";", or even "&" (although the
latter disables prototypes).

- Eric


rvtol+usenet at isolution

Apr 5, 2012, 6:31 AM

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

On 2012-04-04 17:50, Father Chrysostomos via RT wrote:

> How should elsif and else work?

Override them together?

sub my_if_elsif_else {

my $mode = shift; # 1 = if, 2 = elsif, 3 = else
...
}

--
Ruud


ikegami at adaelis

Apr 22, 2012, 1:24 PM

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

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


ikegami at adaelis

Apr 22, 2012, 7:29 PM

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

On Sun, Apr 22, 2012 at 4:56 PM, Father Chrysostomos via RT <
perlbug-comment [at] perl> wrote:

> 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{}?
>
> Im leaning toward the former right now, as it avoids changing the
> behaviour unnecessarily.
>

Would you recommend this behaviour to someone else? Say someone introduces
a C<< with ... in ... >> statement. Should they override C<< in >> so that
C<< in(); >> is a syntax error?

It's going to be fun telling people that Perl goes out of its way to make
C<< elsif(); >> a syntax error just so users can ask Perl not to make it a
syntax error.

- Eric


pagaltzis at gmx

Apr 23, 2012, 3:01 AM

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

* Father Chrysostomos via RT <perlbug-comment [at] perl> [2012-04-22 23:45]:
> 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)).

Should it?

There is a bit of a problem there, isn’t it? 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.

> 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))?

I would tend to go with adding the $_ assignment by default, including
adding it to `while(each %foo)` retroactively, if a scan of the CPAN
shows this to be viable without breaking huge swathes of code. It seems
the Perlish approach to take.

But, extending its coverage to arbitrary user-defined function concerns
me to some extent. As long as only `each`, `glob`, and `readline` get
this treatment, it is predictable what code will do. But if potentially
any sub could get it, then looking at

while (foo $bar, $baz) { ... }

without knowing the definition of `foo` will not tell whether this code
will molest $_.

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

Simple, you have to ensure that your overridden `each` has the exact
same semantics i.e. it can never return undef as part of the data. I see
no problem here.

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

Please let’s not. I like this least of all options.

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


pagaltzis at gmx

Apr 23, 2012, 3:03 AM

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

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

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

If we could get a solid, supported iteration mechanism right into core
that would *rock*. E.g. I remember the struggles PSGI went through for
lack of in-core iterators.

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


nick at ccl4

Apr 23, 2012, 2:02 PM

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

On Sun, Apr 22, 2012 at 02:43:25PM -0700, Father Chrysostomos via RT wrote:
> 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?

I think that $_ = being ommitted on while(each %foo) is not an oversight
at that time.

That commit you quote gets me back to this message from Larry:

As usual, when there are long arguments, there are good arguments for both
sides (mixed in with the chaff). In this case, let's make

while ($x = <whatever>)

equivalent to

while (defined($x = <whatever>))

(But nothing more complicated than an assignment should assume defined().)

http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/1998-04/msg00133.html

Nick Ing-Simmons asks for a clarification:

Thanks Larry - that is what the patch I posted does.

But it also does the same for C<readdir>, C<each> and C<glob> -
i.e. the same cases that solicit the warning in 5.004 is extending
the defined insertion to those cases desirable?
(glob and readdir seem to make sense, I am less sure about each).

http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/1998-04/msg00182.html

(it's clarified in a later message that Nick I-S hadn't realised that each
in *scalar* context returns the keys, so it's an analogous iterator which
can't return undef for any entry)

In turn, the "RULING" dates back to this thread/request:

http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/1998-03/msg01630.html

which also generates a massive thread, of which this message is probably
most insightful:

Pray tell how you can tell that the code is broken without comments in the
code explaining what they expected it to do. while ($x = <>) is legal
code and works as documented. It does not use the idiom of while (<>).

You can't just say "this code is broken" about while ($x = <>) *in all
cases* without more context to indicate the expected behaviour.

http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/1998-03/msg01966.html


in turn that seems to be a reaction to these warnings added in 5.004

$ ./perl -lwe 'while ($a = each %a) {}'
Value of each() operator can be "0"; test with defined() at -e line 1.


[.strictly as far as git has it, most this commit:

commit a60067777be62ee91d1318f9ae26d9ed713245de
Author: Perl 5 Porters <perl5-porters [at] africa>
Date: Wed Jan 1 08:59:00 1997 +1200

[inseparable changes from patch from perl5.003_17 to perl5.003_18]

CORE LANGUAGE CHANGES

...

Subject: Warn on '{if,while} ($x = X)' where X is glob, readdir, or <FH>
From: Chip Salzenberg <chip [at] atlantic>
Files: op.c pod/perldiag.pod

...

as determined by

.../bisect.pl --end perl-5.004 -lwe 'BEGIN {$SIG{__WARN__} = sub {++$b}}; while ($a = <>) {++$a}; exit $b' </dev/null

and the each warning in this commit:

commit 68dc074516a6859e3424b48d1647bcb08b1a1a7d
Author: Perl 5 Porters <perl5-porters [at] africa>
Date: Sun Mar 9 11:57:19 1997 +1200
[inseparable changes from match from perl-5.003_93 to perl-5.003_94]

...

Subject: Warn on C<while ($x = each %y) {}>
From: Chip Salzenberg <chip [at] perl>
Files: op.c pod/perldiag.pod

as determined by

.../bisect.pl --end perl-5.004 -lwe 'BEGIN {$SIG{__WARN__} = sub {++$b}}; while ($a = each %a) {}; exit $b'

]

The rational for the former commit is detailed in the thread starting here:

http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/9612/msg02125.html

the latter in these messages

http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/1997-03/msg01263.html
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/1997-03/msg01302.html



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



The mail archives from 1997 are fascinating. Lots of messages. Lots of
design discussions, not always helpful. And some of the same unanswered
questions as today.


Nicholas Clark


dcmertens.perl at gmail

Apr 23, 2012, 2:19 PM

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

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?

Thanks!
David

--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." -- Brian Kernighan


dcmertens.perl at gmail

Apr 23, 2012, 3:24 PM

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

Got it. That makes sense. Stories about rope come to mind.

Thanks!
David

On Mon, Apr 23, 2012 at 4:55 PM, Father Chrysostomos via RT <
perlbug-followup [at] perl> wrote:

> 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,
> lets just make them all overridable, allowing smarter people to do
> things we havent 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
>



--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." -- Brian Kernighan


fawaka at gmail

Apr 23, 2012, 3:41 PM

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

On Tue, Apr 24, 2012 at 12:21 AM, Father Chrysostomos via RT
<perlbug-followup [at] perl> wrote:
> 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?

That's what mg_copy is for, assuming the magic has a copy method
implemented (I think it doesn't).

Leon


fawaka at gmail

Apr 23, 2012, 4:25 PM

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

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.

Leon


nick at ccl4

Apr 24, 2012, 12:39 AM

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

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?

Nicholas Clark


jvromans at squirrel

Apr 24, 2012, 1:10 AM

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

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

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

Indeed. But I remember long discussions on making changes to perl "just
because we can".

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

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

-- Johan


dcmertens.perl at gmail

Apr 24, 2012, 3:58 AM

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

On Apr 24, 2012 3:10 AM, "Johan Vromans" <jvromans [at] squirrel> wrote:
>
> "Father Chrysostomos via RT" <perlbug-followup [at] perl> writes:
>
> > Overriding if() and being *able* to override if() are two different
> > things.
>
> Indeed. But I remember long discussions on making changes to perl "just
> because we can".
>
> > 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.
>
> > ...lets just make them all overridable, allowing smarter people to do
> > things we havent 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".

I, for my part, hope Perl is shipped on Mars rovers and space stations.
However, the rovers seem unlikely to download updates, so I guess we can
keep our focus on near-earth targets.

:-)

> Let's be a bit careful.
>
> -- Johan


davem at iabyn

Apr 24, 2012, 6:30 AM

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

On Mon, Apr 23, 2012 at 06:11:22PM -0700, Father Chrysostomos via RT wrote:
> 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.

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

I think it likely that the prototype is never freed before the clone;
the clone has a refcounted ptr to the outside sub (CvOUTSIDE), and the
prototype lives in the pad of that outside sub (and so gets duped during
thread creation).


--
"Strange women lying in ponds distributing swords is no basis for a system
of government. Supreme executive power derives from a mandate from the
masses, not from some farcical aquatic ceremony."
-- Dennis, "Monty Python and the Holy Grail"


doy at tozt

Apr 24, 2012, 8:19 AM

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

On Tue, Apr 24, 2012 at 10:10:16AM +0200, Johan Vromans wrote:
> "Father Chrysostomos via RT" <perlbug-followup [at] perl> writes:
> > 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().

The issue is that with the parser changes that have been happening
recently (call_checker, call_parser, etc), there is getting to be less
and less of a difference between these two cases (and ideally, at some
point in the future, there won't be any difference at all). What about
overriding something like map? The distinction isn't quite as clear as
you seem to be implying.

-doy


ikegami at adaelis

Apr 24, 2012, 9:06 AM

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

On Tue, Apr 24, 2012 at 4:10 AM, Johan Vromans <jvromans [at] squirrel> wrote:

> Drawing a line means there's a vast group of keywords (functions) that
> can be overridden, a smaller group that can not


Actually, every keyword can be overridden by other mechanisms. For example,
feature::qw_comments overrides qw, which cannot currently be overridden
using C<< use subs 'qw'; >>

- Eric

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


jvromans at squirrel

Apr 24, 2012, 11:05 AM

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

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.

One of the reasons Perl was conceived many years ago was to take away
the burden from having to keep track of trivial things like arrays,
hashes, memory management, and so on. The Principle Of Least Surprise
was still written with capitals.

Now the goal seems to have become to provide as many rope as possible to
hang oneself.

-- Johan

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.