Dispatch on context
So, I was wondering about how to do multidispatch based on the
context in which something is called, which leads me to wonder if
there's going to be a way of reifying calling context so I could
write:
method whatever($arg1, $arg2)
{ my multi whatever ($self, Scalar $context:
$arg1, $arg2) { ... }
my multi whatever ($self, Array $context:
$arg1, $arg2) { ... }
whatever($_, want(), $arg1, $arg2) }
Just wondering.
Re: Dispatch on context
Piers Cawley writes:
> So, I was wondering about how to do multidispatch based on the
> context in which something is called, which leads me to wonder if
> there's going to be a way of reifying calling context so I could
> write:
>
> method whatever($arg1, $arg2)
> { my multi whatever ($self, Scalar $context:
> $arg1, $arg2) { ... }
> my multi whatever ($self, Array $context:
> $arg1, $arg2) { ... }
> whatever($_, want(), $arg1, $arg2) }
The way I see that happening is if we allow certain kinds of constants
in multi declarations.
my multi whatever ($self, Class $context is derived(Scalar):
$arg1, $arg2) {...}
That'd be nice in a number of different ways. Without this special
feature, an enabling level of indirection can be added with
parameterized types:
my class ClassVal [Class $TYPE] {
# Does nothing, and may even be optimized away
}
my multi whatever ($self, ClassVal[Scalar] $context:
$arg1, $arg2) {...}
# ...
whatever($_, ClassVal[want], $arg1, $arg2);
# ^ does a : go here?
That doesn't handle inheritance correctly, but it can be made to,
provided proper introspection into $TYPE.
Luke
Autovivification (was Re: E6: assume nothing)
Jonadab the Unsightly One said:
> $s = %h{foo} = nonex;
>
> After deleting the foo key (and its value, if any) from %h this then
> probably procedes to autovivify it when evaluating it as an rvalue;
Now why on earth would you want to do that? Perl 5 doesn't.
By the way, I trust this will be addressed (if it hasn't been already):
perl5 -le 'print "gah!" if exists $a{b}{c}; print "phooey!" if exists $a{b}'
perlfunc says:
This surprising autovivification in what does not at first--or even
second--glance appear to be an lvalue context may be fixed in a future
release.
--
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net
This week's summary
The Perl 6 Summary for the week ending 20030907 Welcome to the last Perl 6 summary of my 35th year. Next week's summary will (in theory) be written on my 36th birthday (a year of being square, so no change there then). I'll give you fair warning that it might be late, though it probably won't. Newcastle University has, in its infinite wisdom decided to have its students enrolling on that day so Gill will be off up to Newcastle to register leaving me at home with nothing to do but keep the house tidy in case a buyer wants to come and look at it, so sitting in one place with a laptop writing a summary seems like a good strategy. As last week's 'world turned upside down' approach of starting with perl6-language was such a success we'll do the same again this week. The language list gets some traffic shock! Jonadab the Unsightly One replied to Abhijit A. Mahabal's message from the first of August concerning junctions and set theory. http://xrl.us/sm6 Meanwhile, on perl6-internals Serialization is Hard! Last week's discussion of serialization sparked off by Leopold Tötsch's suggestion of a "vtable->dump" mode *really* got into its stride this week. It turns out that getting this right is a Hard Problem in the presence of threads. Dan's plan for serialization involves using the GC's object graph walker to work out what to serialize when you tell Parrot to dump a PMC. Leo worried that this would essentially stop the garbage collector running during serialization which could be tricky if the serialization process tried to allocate any memory. Dan and Leo ended up in a protracted, but polite, argument about details. At about 45 entries into the thread, Leo produced a summary of the various options and issues associated with them. http://xrl.us/sm7 http://xrl.us/sm8 -- Leo's summary File Spec Leo Tötsch commented on Vladimir Lipskiy's implementation of a File::Spec like tool for Parrot. (File::Spec is Perl's tool for dealing with filenames and paths in a platform independent fashion). Michael Schwern pointed at Ken Williams' "excellent Path::Class module which gives you actual file and directory objects" which he reckons has a much better interface than File::Spec. http://xrl.us/sm9 Notifications Gordon Henriksen posted a great discussion of using notifications to implement weakrefs. Rather wonderfully he used the notification system itself as a good example of why dying object notifications were a good idea. http://xrl.us/sna Parrot 100% GNU .NET Danger. Here be Licensing Issues. I don't do Licensing issues. The main thrust of the discussion was what kind of library would ship with Parrot. Dan's answer is worth reading, if only for the "That's a swamp I don't have enough castles for" line. http://xrl.us/snb http://xrl.us/snc -- Dan's take on the library You are in a maze of keyed variants, all similar This seems to have been a week in which Dan and Leo spent a good deal of their time politely disagreeing with each other. This time they were disagreeing about the need for all the keyed variants of Parrot's opcodes. Dan outlined the reasoning behind demanding keyed variants of every operation in a PMC's vtable (Executive summary: A combination of speed and space reasons). Leo still doesn't seem convinced but, for now, Pumpking trumps Patch monster. http://xrl.us/snd Parrot Z-machine Amir Karger's post from last week about implementing the Z-machine (the VM that runs Infocom and other text adventures) got de-Warnocked this week. Nicholas Clark explained that doing the Z-machine 'properly' would require some bits of Parrot that weren't actually there yet, specifically dynamic opcode loading and dynamic bytecode conversion. This led to a discussion of how to get those things implemented. http://xrl.us/rtr PIO Questions Benjamin Goldberg posted a long list of issues and suggestions about handling character type and encoding on Parrot IO objects. Jürgen Bömels said that there were indeed issues, that he'd be dealing with them as tuits allowed and that patches are welcome. http://xrl.us/sne How to dynamically add a method to a class Joseph Ryan had asked how to add a method to a class at runtime. Dan explained what was supposed to happen (each class has a 'backing namespace' associated with it which contained all the class's methods). Leo asked for a few details about how that would look in Parrot assembly. A little later, Joseph reported what appeared to be a bug in the way IMCC handles ".namespace". It appears that IMCC is working as designed, the question is whether the design is doing the Right Thing. http://xrl.us/snf http://xrl.us/sng Proposed amendment to charty
