*Tap Tap*
Is this thing on? No messages since last Wednesday. Which admittedly makes a summarizer's life a good deal easier... -- Piers
Re: *Tap Tap*
On Mon, Jun 09, 2003 at 09:56:06AM +0100, Piers Cawley wrote: > Is this thing on? No messages since last Wednesday. Which admittedly > makes a summarizer's life a good deal easier... It looks like it is. However, your life may be easier "this week" only, given that many armed and dangerous minds have been meeting up on the perl whirl, and may be about to unleash fearsome new concepts to the world. So it may only be the calm before the storm. Or I may be wrong. Nicholas Clark
Re: *Tap Tap*
Nicholas Clark <[EMAIL PROTECTED]> writes: > On Mon, Jun 09, 2003 at 09:56:06AM +0100, Piers Cawley wrote: >> Is this thing on? No messages since last Wednesday. Which admittedly >> makes a summarizer's life a good deal easier... > > It looks like it is. > > However, your life may be easier "this week" only, given that many > armed and dangerous minds have been meeting up on the perl whirl, and > may be about to unleash fearsome new concepts to the world. So it may > only be the calm before the storm. Or I may be wrong. Ah well, I'll be in Florida for the next one, hopefully I'll be able ask some of said dangerous minds what on earth they're talking about. Anyhoo, time to get this week's summary mailed out. -- Piers
Re: This week's summary
On Mon, Jun 09, 2003 at 01:26:22PM +0100, Piers Cawley wrote:
> Multimethod dispatch?
> Adam Turoff asked if multimethod dispatch (MMD) was really *the* Right
> Thing (it's definitely *a* Right Thing) and suggested that it would be
> more Perlish to allow the programmer to override the dispatcher,
> allowing for all sorts of more or less cunning dispatch mechanisms
> (which isn't to say we could still have MMD tightly integrated, but it
> wouldn't be the *only* alternative to simple single dispatch). Luke
> Palmer gets the "Pointy End Grandma" award for pointing out that Perl 6
> is a '"real" programming language now' (as Adam pointed out, Perl's been
> a 'real' programming language for years), inspiring a particularly pithy
> bit of Cozeny. As far as I can tell, Adam wants to be able to dispatch
> on the runtime value of a parameter as well as on its runtime type (he's
> not alone in this). Right now you either have to do this explicitly in
> the body of the subroutine, or work out the correct macromantic
> incantations needed to allow the programmer to use 'nice' syntax for
> specifying such dispatch.
>
> Assuming I'm not misunderstanding what Adam is after, this has come up
> before (I think I asked about value based dispatch a few months back)
> and I can't remember if the decision was that MMD didn't extend to
> dispatching based on value, or if that decision hasn't been taken yet.
> If it's not been taken, I still want to be able to do
>
>multi factorial (0) { 1 }
>multi factorial ($n) { $n * factorial($n - 1) }
That's pretty much correct.
I've been musing on dispatching over the last week, and I've come
up with a few scenarios:
- pure type-based (match a method's signature, modulo superclasses)
- pure value-based (scalars with specific values)
- mixed-mode (RightMouseClick class, with 'control' modifier set/unset)
- pre-/post- methods; chains of pre-/post- methods
- AOP-style pre-/post- methods that can come and go at runtime
- Eiffel-style contract checking/enforcement
- roll-your-own inheritance mechanisms (see NEXT.pm)
I've also considered "side-effect based dispatching" for lack of a better
term: Consider an object with a whole gaggle of methods that need to check
whether the database is up before continuing. All of them fail similarly
with a "database is down" error. Why *not* factor that out into a
different set of multimethods that execute only when the database is down?
Now consider what happens if the database handles are not parameters to
each method call, but slots in the object or stored globally...
There are a few other, admittedly weird scenarios where this kind of
behavior would be desirable. All of them exhibit an AOP-ish quality.
Anyway, as Piers summarized, my concern is that if there's only two types
of dispatching, it may be artificially limiting. I'm guessing that if I
can think of three dispatching behaviors, then there may be five, and if
there really are five then there just might be as many as ten or more.
Therefore the simple dispatch/type-based MMD dispatch duality limits more
than it empowers.
I don't think this is really a problem to be solved in the domain of
macro expansion or syntactic warpage. Writing classes to handle these
rules feels like the way to go. Whether or not MMD as it's been sketched
is hardwired into the language (e.g. for performance) is less important to
me than the ability to plug in different (levels of) dispatching behaviors.
Z.
Re: This week's summary
On Mon, 9 Jun 2003, Adam Turoff wrote: > - roll-your-own inheritance mechanisms (see NEXT.pm) On a related note, you might also want to take a look at CLOS (the Common Lisp Object System) where it talks about method selection. They've got a pretty clear and general model that describes every imaginable (and unimaginable) thing you'd want to do with dispatch. It's broken into 3 steps, any one of which you can customize: - find all applicable methods - sort them in order of specificity - apply some kind of combining operation to this list (e.g. select 1st) Granted, this is hardly efficient, and from what I've seen you need to be careful in how you use MMD to get decent performance in Lisp. But it's still helpful in laying out the design space. /s
Re: This week's summary
On Mon, Jun 09, 2003 at 01:26:22PM +0100, Piers Cawley wrote:
Multimethod dispatch?
Assuming I'm not misunderstanding what Adam is after, this has come up
before (I think I asked about value based dispatch a few months back)
and I can't remember if the decision was that MMD didn't extend to
dispatching based on value, or if that decision hasn't been taken yet.
If it's not been taken, I still want to be able to do
multi factorial (0) { 1 }
multi factorial ($n) { $n * factorial($n - 1) }
That's a bad example, as it's really not MMD. It's a partially
pre-memoized function instead.
Which brings up a issue. Is it really MMD if you're only dispatching on
a single invocant? Most of the examples I've seen for MMD so far use
only a single invocant and are really either regular dispatch or simple
overloading instead. MMD only becomes really interesting if you
have multiple invocants possibly with best-match signature matching
involved.
--
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Re MMD [was Re: This week's summary]
On Monday, June 9, 2003, at 07:13 AM, Adam Turoff wrote:
On Mon, Jun 09, 2003 at 01:26:22PM +0100, Piers Cawley wrote:
Assuming I'm not misunderstanding what Adam is after, this has
come up
before (I think I asked about value based dispatch a few months
back)
and I can't remember if the decision was that MMD didn't extend to
dispatching based on value, or if that decision hasn't been taken
yet.
If it's not been taken, I still want to be able to do
multi factorial (0) { 1 }
multi factorial ($n) { $n * factorial($n - 1) }
The most recent semi-official opinion given onlist, AFAIK, was from
Damian on 3/13/03:
On Thursday, March 13, 2003, at 06:15 PM, Damian Conway wrote:
Piers Cawley wrote:
Speaking of multis and constants, Greg McCarroll wondered on IRC if
this would work:
multi factorial (Int 0) { 1 }
multi factorial (Int $n) { $n * factorial($n-1) }
Probably not. We did discuss whether multimethods should be able to be
overloaded by value, but concluded (for that week, at least ;-) that
this might prove syntactically excessive.
See the rest of his message for a marginally scary workaround.
MikeL
Re: MMD [was Re: This week's summary]
On Monday, June 9, 2003, at 09:19 AM, Mark A. Biggar wrote:
On Mon, Jun 09, 2003 at 01:26:22PM +0100, Piers Cawley wrote:
multi factorial (0) { 1 }
multi factorial ($n) { $n * factorial($n - 1) }
That's a bad example, as it's really not MMD. It's a partially
pre-memoized function instead.
It's MMD if you think of the number 0 as being a "subclass" of C
or C. In other words, you have an C class, and then a
subclass of C that binds the value to always be zero.
In a not-too-twisted fashion, you can think of any constant as being a
"subclass" of its base type, overridden to store exactly one possible
value. It's like instance-based (classless) inheritance, which we
haven't discussed much, but which I hope we eventually get to, because
it's bloody useful... Sigh...
Which brings up a issue. Is it really MMD if you're only dispatching
on
a single invocant? Most of the examples I've seen for MMD so far use
only a single invocant and are really either regular dispatch or simple
overloading instead. MMD only becomes really interesting if you
have multiple invocants possibly with best-match signature matching
involved.
I think it's a matter of semantics: a single-invocant routine is still
a "multi", and still semantically MMD, because it uses the same
internal dispatcher as an N-invocant one, and checks the same list of
possible variants. So you can have:
multi bar (Baz $b : ...); # one invocant
multi bar (Foo $f : ...); # one invocant, but different!
multi bar (Foo $f, Baz $b : ...); # two invocants
All three of those are multimethod variants of a routine named C.
The MMD mechanism has to determine which of those three variants to
use, based on the invocant(s) -- of which there may be one, or several,
for any given call to C. Even if there only happens to be one
invocant, it's still the same dispatcher, sifting through the same
possible variants.
The single-invocant C thing I still find confusing at this point
is that, for example, you can't actually have Cs! That
is, you can't do this:
class Foo {
method bar (int $i);
method bar (str $s); # ERROR
method bar (str $s1, str $s2);
}
You'd have to do this:
class Foo {
multi bar (Foo $self, int $i : ); # semicolon optional
multi bar (Foo $self, str $s : );
multi bar (Foo $self, str $s1, str $s2 : );
}
Which, internally, makes some sense -- they have to go to a more
complicated dispatcher than normal methods -- but is semantically icky,
IMO, and I hope/wish we could find a better way of expressing that.
Perhaps E6 will help.
MikeL
Re: MMD [was Re: This week's summary]
"Michael Lazzaro" <[EMAIL PROTECTED]> wrote
> multi bar (Foo $self, int $i : ); # semicolon optional
I think you meant "colon optional". The semi-colon is, I think, a syntax
error. You need the yada-yada-yada thing: "{...}".
But I agree with the main point you were wanting to make: a class-based
multimethod really should make the primary invocant ($self) implicit -- if
doing so doesn't make things even more confusing/ambiguous/nasty.
Dave.
Re: MMD [was Re: This week's summary]
On Monday, June 9, 2003, at 03:45 PM, Dave Whipp wrote:
"Michael Lazzaro" <[EMAIL PROTECTED]> wrote
multi bar (Foo $self, int $i : ); # semicolon optional
I think you meant "colon optional". The semi-colon is, I think, a
syntax
error. You need the yada-yada-yada thing: "{...}".
Sigh. Yes, thank you. This, not that:
multi bar (Foo $self, int $i : ) {...} # colon optional
It's been a bad day. :-/
MikeL
This week's summary
The Perl 6 Summary for the week ending 20030608 It's another Monday, it's another summary and I need to get this finished so I can starting getting the house in order before we head off to Boca Raton and points north and west on the long road to Portland, Oregon. Via Vermont. (I'm English and as the poem comments, the rolling English road is "A rare road, a rocky road and one that we did tread // The day we went to Birmingham by way of Beachy Head." Just because I'm in America doesn't mean I can't take an English route to OSCON) We'll start with the internals list this week (and, given that there are only 18 or so messages in my perl6-language inbox, we may well stop there). Building IMCC as parrot It's been pretty much decided that IMCC will soon become 'the' parrot executable. Josh Wilmes, Robert Spier and Leo "Perl Foundation grant recipient" Tötsch are looking into what needs to be done to make this so. It's looking like the build system may well see some vigorous cleanup action in this process. http://xrl.us/jax The Horror! The Horror! Clint Pierce continued to expand on the internals of this Basic implementation. The more I see of his pathological examples, the gladder I am that I escaped BASIC as quickly as possible. Still, kudos to Clint once more for the effort, even if it is a tad embarrassing that the most advanced language hosted on Parrot is BASIC. (On IRC Leon Brocard and others have been heard to remark that they're? unlikely to go all out at a real language until Parrot has objects. Dan?) http://xrl.us/jay The Horror! The Horror! Part II The timely destruction thread still doesn't want to go away. Dan has been heard muttering about this on IRC. Eventually, he did more than mutter on IRC -- he stated clearly on list that 'We aren't doing reference counting' and that as far as he is concerned the matter is closed. Dan's blog also has another of his excellent "What The Heck Is" posts, this time about Garbage Collection. http://xrl.us/jaz http://xrl.us/ja2 http://xrl.us/ja3 - What the Heck is: Garbage Collection The Continu(ation)ing Saga Jonathan Sillito posted a longish meditation on Parrot's new continuation passing calling conventions. He wondered if, now we have continuation passing, we really needed the various register stacks that were used in the old stack based calling conventions. Warnock's Dilemma currently applies. http://xrl.us/ja4 Clint Pierce, IMCC tester extraordinaire Over the past couple of week's Clint Pierce has been porting his BASIC implementation over to run on IMCC. In the process of doing so he's been finding and reporting all sorts of IMCC bugs and/or misunderstandings and Leo Tötsch (usually) has either been correcting Clint's assumptions or fixing the bugs he's found. I've mentioned a few of these exchanges that generated longish threads in the past, but that hasn't covered everything that's been found, discussed and fixed. It's been great to see this sort of dialogue driving the design and implementation forward based on the needs of a real program. The thread I've linked to below is another exchange in this ongoing dialogue. Clint found a way of reliably segfaulting IMCC. Leo fixed it. And on to the next. http://xrl.us/ja5 And, on the subject of list stalwarts... Jürgen Bömmels is still working away at the Parrot IO (PIO) subsystem. In this particular patch, he's gone through the Parrot source replacing occurrences "PIO_fprintf(interpreter, PIO_STDERR(interpreter, ...)" with the better factored "PIO_eprintf(interpreter, ...)", which as well as eliminating repetition, helps to keep the IO code slightly easier to maintain. Leo applied the patch. (Although it's not mentioned explicitly elsewhere, Leo continues to keep up his astonishing productivity with various other patches to Parrot) http://xrl.us/ja6 Make mine SuperSized Bryan C. Warnock continued to discuss issues of the size of Parrot's various types, particularly the integer types that get used within a running Parrot. Bryan argues that these should ideally use a given platform's native types, worrying about guaranteed sizes only at the bytecode loading/saving stage. Dan and others commented on this (Dan essentially said that he understood what Bryan was driving at but wasn't quite sure of the way forward, and outlined his options). Discussion continues. http://xrl.us/ja7 Call "invoke" call? Jonathan Sillito submitted a patch which changes "invoke" to "call", adds some PMC access macros and updates the tests. He and Leo Tötsch discussed things for a while and I think the patch is in the process of being rewritten as result of that discussion. http://xrl.us/ja8 Constant
