New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
|| && and or cannot be "overloaded" #5997
Comments
From @FCOIf I write another || operator it will continue to use the original version. https://irclog.perlgeek.de/perl6/2017-01-10#i_13895823 <https://irclog.perlgeek.de/perl6/2017-01-10#i_13895823> |
From @zoffixznetOn Tue, 10 Jan 2017 16:23:18 -0800, fernandocorrea@gmail.com wrote:
To save other readers sifting through the chan log... Even an only sub doesn't take root: <Zoffix> m: sub infix:<||> ( This applies to &&, and, or, and I'd guess any shortcurcuiting operator. |
The RT System itself - Status changed from 'new' to 'open' |
From @jnthnOn Tue, 10 Jan 2017 17:59:05 -0800, cpan@zoffix.com wrote:
These are special compiler forms that receive special code-gen, due to their shortcircuiting nature, and so do not result in sub calls. Thus there's no sub to override. |
From @LLFournThere is a &infix:<&&> which might be where some confusion comes from. I multi sub infix:<&&>("foo","bar") { "win" }; so it does kinda work actually just not as you might expect. LL On Thu, Jan 12, 2017 at 9:21 AM jnthn@jnthn.net via RT <
|
From @lizmat[10:04:44] <lizmat> re the shortcircuiting behaviour of && || and friends, and the fact you cannot override them (RT #130540)
|
From @smls@lizmat: Aren't signatures that affect how a function call is parsed/compiled (a la Perl 5 "prototypes"), something that Perl 6 intentionally moved away from? Regarding the "thunky" operators like ||, &&, xx: My conceptual view of them, is that each of them exists simultaneously as a macro (that offers the short-circuiting/lazy-evaluation behavior) and as function (which accepts Perl 6 objects rather than thunks). The macro clobbers the function, so when the operator is encountered normally in the source code, the compiler (conceptually) invokes the macro, thus generating code for the lazy evaluation behavior. But you actually *can* get at the function version as well, which obviously can't be short-circuiting/lazy: ➜ say &[||] In this view, adding a multi candidate to the function does nothing to override the macro, so this wouldn't be considered a bug. Rather, the solution would be to provide sufficiently flexible macro functionality to allow users to override or extend these built-in macros. |
From @FCOBut should those 2 forms behave differently? 20:40 <SmokeMachine> m: multi infix:<||>(42, 42) {"OK"}; say infix:<||>(42, 42); say 42 || 42 Enviado do meu iPhone
|
From @bdwI'm not sure if this adds anything, but: Regards, 2017-01-11 23:42 GMT+01:00 Fernando Oliveira <fernandocorrea@gmail.com>:
|
Migrated from rt.perl.org#130540 (status was 'open')
Searchable as RT130540$
The text was updated successfully, but these errors were encountered: