Re: proposal: binding with a function
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] writes:
As I've said before, Perl supports `alias`--it's just spelled `:=`.
Here's a rubyish idiom:
my old_behaviour := function;
function := sub { try_some_stuff || old_behaviour }
Except, with binding it doesn't work like that, you end up with an infinite
loop.
Re: proposal: binding with a function
Piers Cawley skribis 2005-06-23 15:30 (+0100):
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] writes:
As I've said before, Perl supports `alias`--it's just spelled `:=`.
Here's a rubyish idiom:
my old_behaviour := function;
function := sub { try_some_stuff || old_behaviour }
Except, with binding it doesn't work like that, you end up with an infinite
loop.
I still think subs should have a value, than can be copied :)
my old_behaviour = function;
function = sub { try_something || old_behaviour };
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: proposal: binding with a function
Hi,
Juerd juerd at convolution.nl writes:
Piers Cawley skribis 2005-06-23 15:30 (+0100):
Brent 'Dax' Royal-Gordon brentdax at gmail.com writes:
As I've said before, Perl supports `alias`--it's just spelled `:=`.
Here's a rubyish idiom:
my old_behaviour := function;
function := sub { try_some_stuff || old_behaviour }
Except, with binding it doesn't work like that, you end up with an
infinite
loop.
I still think subs should have a value, than can be copied :)
my old_behaviour = function;
function = sub { try_something || old_behaviour };
I absolutely agree!
But: Your example won't work correctly, as function() would
return a Code reference (old_behaviour) instead of calling
old_behaviour, wouldn't it?
I think all of the following should work:
my old_behaviour = function;
function = sub { try_something() || old_behaviour() };
my old_behaviour = function;
function := sub { try_something() || old_behaviour() };
Additionally, with nothingmuch's lazy {...} proposal, the
following should work, too (I think):
my old_behaviour = function;
function = lazy { try_something || old_behaviour };
my old_behaviour = function;
function := lazy { try_something || old_behaviour };
--Ingo
--
Linux, the choice of a GNU | When cryptography is outlawed, bayl bhgynjf
generation on a dual AMD | jvyy unir cevinpl!
Athlon!|
Re: AUTLOAD and $_
Luke Palmer [EMAIL PROTECTED] writes:
On 6/20/05, chromatic [EMAIL PROTECTED] wrote:
On Mon, 2005-06-20 at 12:11 +0200, Juerd wrote:
I think there exists an even simpler way to avoid any mess involved.
Instead of letting AUTOLOAD receive and pass on arguments, and instead
of letting AUTOLOAD call the loaded sub, why not have AUTOLOAD do its
thing, and then have *perl* call the sub?
Who says AUTOLOAD will always either call a loaded sub or fail?
Uh, what else can it do? It doesn't have to load a sub to return a
code reference.
For myself, I'd like to see AUTOLOAD with a signature along the lines of:
sub AUTOLOAD (Symbol $sym, ArgumentCollection $args, Continuation $cc)
returns (Code | Pair)
{
...
}
This presupposes a deal of support infrastructure, but also provides
flexibility. For the 'NullObject' case, you'd simply do C$cc() to return
directly to the caller, skipping over whatever Perl is up to.
'ArgumentCollection'? Well, that's the activation record and I'd like to see it
allowing methods like:
my ($foo, $bar, $baz) =
$args.parse_signature('Int $foo, String $bar, Code $baz')
That way code could probe the argument structure in order to do its own
dispatch.
As for returning a coderef or a pair. If you return a coderef, Perl simply
calls it and throws it away. Returning a pair, with a name (long or short) as
the key and the code as the value would make perl bind the code to the given
name (which should be compatible with the name passed in in the first place).
Details left as an exercise for the interested reader.
This week's summary
The Perl 6 summary for the fortnight ending 2005-06-21 Surprise! It's me again. You may be wondering what happened to last week's summary (I know I was) and where Matt had gone. Well, I'm not entirely sure where exactly he is now, but last week was moving week for him. Those of you reading this on the mailing lists may also be wondering why this summary is so late. Um... three words: World of Warcraft. This week in perl6-compiler As a Summarizer, when you see the 'last fortnight' view of a mailing list containing 21 messages, several thoughts spring, unbidden, to your mind: Is my mail broken again? Has everyone given up? Phew, this group won't take long to do. It turns out that the answer to both of those questions is No. What actually happened was that most of the stuff that normally happens in mail happened at the Austrian Perl Workshop and Leo Tötsch's house, with a side order of IRC conversation. Oh, and a bunch of spin off threads in p6l and p6i. So, in the last fortnight Pugs reached the point where it has a (mostly) working Parrot back end and BÁRTHAZI Andras wondered if we shouldn't start a perl6-general mailing list. http://xrl.us/gia7 - Autrijus's Pugs development journal http://xrl.us/gia8 - perl6-general anyone? This week in perl6-internals 140 messages in this one. p6c lulled me into a false sense of security. Again, you may notice a bewilderingly fast rate of change this summary. It turns out that they weren't just working on Pugs at Leo's house. Perl 6 Hackathons give great productivity. This is not your father's Parrot There's been some serious work going on under the Parrot hood in the last two weeks. The calling conventions have been drastically reworked and now uses 4 new opcodes, set_args, set_returns, get_params and get_results. At the time of writing, IMCC doesn't give you full syntactic help with them, but they're easy enough to use explicitly for the time being and the help is getting there. Check out the PDD for details. Also getting rejigged is the continuation/register frame architecture. Taking advantage of the fact that this is a *virtual* machine, we now have an unlimited number of registers per register frame. Combine this with the new calling conventions, in which arguments are passed outside the register frame and all of a sudden a full continuation becomes a simple pointer to the register frame and everything gets saved as if by magic. Which opens up a whole bunch of possibilities. Which has interesting implications for the register allocator. http://xrl.us/gia9 -- The new calling conventions http://use.perl.org/~chip/journal/ -- Chip's design notes New Generational GC scheme Alexandre Buisse posted his outline for a Google Summer of Code project to implement a shiny new Generational Garbage Collection scheme. Discussion of tunability and threading issues followed. http://xrl.us/giba Ordered Hashes -- more thoughts Steve Tolkin helpfully provided a summary of his thoughts about ordered hashes: An ordered hash that does not support deletes could cause a user visible bug. At a minimum it should support the special case of delete that is supported by the Perl each() operator. Dan pointed out that reusing the ordered hash code for anything other than the lexical pad it was specifically implemented for was just looking for trouble. http://xrl.us/gibb The thread that I really hoped Matt would be summarizing AKA Attack of the 50 foot register allocator vs. the undead continuation monster. Piers Cawley and Chip had something of a disagreement about interactions between continuations and the register allocator. After discussion on IRC it became apparent that they were talking past each other. The new 'the register frame is the continuation' means that yes, the register allocator definitely can't rely on being able to reuse registers that persist over function calls, but that's all right because you can always grab more registers. http://xrl.us/gibc Missing MMD default functions Remember the missing Multimethod functions I mentioned last time. At the time Chip hadn't ruled on whether taking them out was the Right Thing or not. He has since ruled that it was. This is probably not quite the right place to suggest this, but what the heck. Maybe in future when user visible changes of this sort are planned they should spend at least one release period deprecated and throwing warnings when used. http://xrl.us/gibd PGE, namespaced rules William Coleda worried that PGE subrules appear to be globally scoped. It turns out that Patrick worries too, but is currently in the process of thrashing out how they should be scoped. He outlined his current thinking.
This week's summary, correctly formatted
The Perl 6 summary for the fortnight ending 2005-06-21 Surprise! It's me again. You may be wondering what happened to last week's summary (I know I was) and where Matt had gone. Well, I'm not entirely sure where exactly he is now, but last week was moving week for him. Those of you reading this on the mailing lists may also be wondering why this summary is so late. Um... three words: World of Warcraft. This week in perl6-compiler As a Summarizer, when you see the 'last fortnight' view of a mailing list containing 21 messages, several thoughts spring, unbidden, to your mind: Is my mail broken again? Has everyone given up? Phew, this group won't take long to do. It turns out that the answer to both of those questions is No. What actually happened was that most of the stuff that normally happens in mail happened at the Austrian Perl Workshop and Leo Tötsch's house, with a side order of IRC conversation. Oh, and a bunch of spin off threads in p6l and p6i. So, in the last fortnight Pugs reached the point where it has a (mostly) working Parrot back end and BÁRTHAZI Andras wondered if we shouldn't start a perl6-general mailing list. http://xrl.us/gicz - Autrijus's Pugs development journal http://xrl.us/gic2 - perl6-general anyone? This week in perl6-internals 140 messages in this one. p6c lulled me into a false sense of security. Again, you may notice a bewilderingly fast rate of change this summary. It turns out that they weren't just working on Pugs at Leo's house. Perl 6 Hackathons give great productivity. This is not your father's Parrot There's been some serious work going on under the Parrot hood in the last two weeks. The calling conventions have been drastically reworked and now uses 4 new opcodes, set_args, set_returns, get_params and get_results. At the time of writing, IMCC doesn't give you full syntactic help with them, but they're easy enough to use explicitly for the time being and the help is getting there. Check out the PDD for details. Also getting rejigged is the continuation/register frame architecture. Taking advantage of the fact that this is a *virtual* machine, we now have an unlimited number of registers per register frame. Combine this with the new calling conventions, in which arguments are passed outside the register frame and all of a sudden a full continuation becomes a simple pointer to the register frame and everything gets saved as if by magic. Which opens up a whole bunch of possibilities. Which has interesting implications for the register allocator. http://xrl.us/gic3 -- The new calling conventions http://use.perl.org/~chip/journal/ -- Chip's design notes New Generational GC scheme Alexandre Buisse posted his outline for a Google Summer of Code project to implement a shiny new Generational Garbage Collection scheme. Discussion of tunability and threading issues followed. http://xrl.us/gic4 Ordered Hashes -- more thoughts Steve Tolkin helpfully provided a summary of his thoughts about ordered hashes: An ordered hash that does not support deletes could cause a user visible bug. At a minimum it should support the special case of delete that is supported by the Perl each() operator. Dan pointed out that reusing the ordered hash code for anything other than the lexical pad it was specifically implemented for was just looking for trouble. http://xrl.us/gic5 The thread that I really hoped Matt would be summarizing AKA Attack of the 50 foot register allocator vs. the undead continuation monster. Piers Cawley and Chip had something of a disagreement about interactions between continuations and the register allocator. After discussion on IRC it became apparent that they were talking past each other. The new 'the register frame is the continuation' means that yes, the register allocator definitely can't rely on being able to reuse registers that persist over function calls, but that's all right because you can always grab more registers. http://xrl.us/gic6 Missing MMD default functions Remember the missing Multimethod functions I mentioned last time. At the time Chip hadn't ruled on whether taking them out was the Right Thing or not. He has since ruled that it was. This is probably not quite the right place to suggest this, but what the heck. Maybe in future when user visible changes of this sort are planned they should spend at least one release period deprecated and throwing warnings when used. http://xrl.us/gic7 PGE, namespaced rules William Coleda worried that PGE subrules appear to be globally scoped. It turns out that Patrick worries too, but is currently in the process of thrashing out how they should be scoped. He outlined his current thinking.
Re: proposal: binding with a function
Piers Cawley wrote:
Here's a rubyish idiom:
my old_behaviour := function;
function := sub { try_some_stuff || old_behaviour }
Except, with binding it doesn't work like that, you end up with an infinite
loop.
But this version *should* work correctly:
# Bind the name 'old_behaviour' to the closure that is currently bound to
# the name 'function'...
my old_behaviour := function;
# Rebind the name 'function' to the specified closure, calling the
# old behaviour (via its new name) if necessary...
function := sub { try_some_stuff || old_behaviour([EMAIL PROTECTED]) };
No infinite loop involved.
Perl 6 even has specific syntactic sugar for this kind of thing:
function.wrap( { try_some_stuff || call([EMAIL PROTECTED]) } );
See: http://dev.perl.org/perl6/doc/design/syn/S06.html#Wrapping
Damian
