Re: Come and get me, Schwern

[Bart Lateur]

On Wed, 29 Aug 2001 16:26:59 -0500, David L. Nicol wrote:

>Bill J. Programmer publishes a class foo that is guaranteed to correctly
>blarg the frobniz, someone subclasses it and breaks the blarg function,
>that simply will not do!
>
>With a "final" it is no longer possible for the new class to identify
>itself as a foo.

It's not a foo. It's instance of a *subclass* of foo. If it can't be
different than foo, then you might just as well toss out the idea of
subclassing altogether.

Look at the "lame duck" example on this page:
. So you say a duck
has two legs. That's fine as a default. But a lame duck, with one leg
missing, only has one leg. So if you make the number of legs (or feet)
of a duck "final", then lame ducks can't be ducks. Or they can be ducks,
but then they can't have but one leg.

-- 
Bart.

Re: CLOS multiple dispatch

[Dan Sugalski]

On Thu, 30 Aug 2001, Damian Conway wrote:

>> Even if the dispatcher is the heart of multimethods, perhaps it
>> would be nice if it were convenient to replace the dispatcher
>> in whole or part.
> 
> I'm sure if we asked Dan nicely, he'd consider hanging the dispatcher on
> a lexically-scoped hook to make that possible ;-)

I'd planned on making the dispatch one of the vtable methods for
variables, so you could override it on a per-class or per-object basis if
you wanted. (Most people, I expect, will choose one of the standard
dispatchers, and there will probably be two or three)

I hadn't considered having it as a global thing, just because I can see
class Foo wanting multimethods, and class Bar being fine with 'normal'
class hierarchy walking, and class Baz deciding it wants the automatic
redispatch form of method calling.

We could make it a global thing and have only a single way to dispatch, in
which case it would be lexically overridable, but that seems awfully
limiting...

Dan

Re: CLOS multiple dispatch

[Damian Conway]

   > Even if the dispatcher is the heart of multimethods, perhaps it
   > would be nice if it were convenient to replace the dispatcher
   > in whole or part.

I'm sure if we asked Dan nicely, he'd consider hanging the dispatcher on
a lexically-scoped hook to make that possible ;-)

Damian

Re: Final, no really, Final draft: Conventions and Guidelines for Perl Source Code

[Simon Cozens]

On Thu, Aug 23, 2001 at 08:11:26PM -0400, Robert Spier wrote:
> How about something a little more explicit than XXX, like TODO or FIXME?

Some syntax-highlighting editors highlight "XXX". Let's use that feature.

And how can you get more explicit than XXX, anyway?

> > In function definitions, the name starts in column 0, with the
> > return type on the previous line
> 
> Eww.  Why do we want this again?

1) Dicky C compilers
2) Ease of parsing. (By our own tools that is, not by cc)

> > /*=for api apiname entityname[,entityname..] flags (TBC)
> > comments
> > */
> 
> This is perl5ish syntax.  Has there been thought about a different syntax here?

I'd prefer to go the other way, and just have POD everywhere. At the moment,
I'm spec'ing out the API for various functions by embedding POD in C comments;
I can then just run perldoc on a plain old C file, and I've got an API document.

 % perldoc bytecode.c
BYTECODE.C(1)  User Contributed Perl Documentation  BYTECODE.C(1)

Bytecode Manipulation Functions
   This file, "bytecode.c", contains all the functions
   required by the core for the processing of the structure
   of a bytecode file. It is not intended to understand the
   bytecode stream itself, but merely dissect and reconstruct
   data from the various other segments. See the parrotbyte
   manpage for information about the structure of the frozen
   bycode.

   "check_magic"
  Args: void** program_code

  Check to see if the first "long" in *program_code
  matches the Parrot magic number for bytecode; return 1
  if so, and 0 if not. This function is expected to
  advance the *program_code pointer beyond the magic num-
  ber.

   "read_constants_table"
  Args: void** program_code

  UNIMPLEMENTED.

  Reads the constants segment from *program_code, and
  creates the referenced constants. See the Constants
  Segment entry in the parrotbyte manpage for the struc-
  ture of the constants segment. Advances *program_code
  beyond the constants segment.

...

Cool, eh?

Yeah, ideally the function declarations can be parsed to automatically
generate documentation about the return values and the arguments, but hey,
perldoc already exists, and I'm too lazy to write a sophisticated C
code parser. (Even with C::Scan.) 

This may just be a temporary measure to help me spec out what functions
we need writing. I have a feeling that leaving big swathes of
implementation details in there as POD will clutter up the C file. But
once again, the beauty of doing it all in POD is that we have the tools
to extract it to another file if and when we need to.

Incidentally, things like the above will eventually turn into PIS 
(Parrot Interface Specification) documents. I'll send some of these
out hopefully by the end of next week, and encourage people to pick
some functions and implement them. It's almost time to start coding,
people, almost.

Simon

RE: CLOS multiple dispatch

[Hong Zhang]

> For example, here is an event handler for a GUI:
> 
>   sub handle (Window $w, Event $e) : multi {
>   log("Unknown event $($e->desc) called on window
$($w->name)");
>   }
> 
>   sub handle (Window $w, CloseEvent $e) : multi {
>   $w->close;
>   }
> 
>   sub handle (ImportantWindow $w, CloseEvent $e) : multi {
>   $w->close if yesno_dialog("Really close this window???");
>   }
> 
>   sub handle (Window $w, MoveEvent $e) : multi {
>   $w->moveto($e->newpos);
>   }
> 
>   sub handle (FixedWindow $w, MoveEvent $e) : multi {
>   beep();
>   }
> 
> Note that the handler that is selected depends on the *combination* of
> the types of the two arguments. And that the dispatcher understands
> the argument/parameter inheritance relationships and selects the most
> specific handler for each combination. For example, a MoveEvent sent to
> a FixedWindow causes a beep, but a MoveEvent sent to any other type of
> window is dispatched to the more-generic handle(Window $w, MoveEvent $e)
> subroutine, which causes it to move.

I believe this feature has some conflict with OO dispatch. In a pure
static procedure language, this can be nicely and easily done. I am not
if we really this for Perl.

1) How do we find the method if the package is lazy loaded? The "sub"
can sit in some package that is irrelavent to the argument types. How
can runtime decide whether to use handle(Window $w, Event $e) or try
to load some 'magik' package, which happens to define 
handle(Window $w, FooEvent $e).

2) If there is mismatch on more than one argument type, which argument
should be favored more than the others.

3) The multi dispatch is generally slow and complicated. Since it does
not fit well with OO concept, it will just cause more confusion. Typically
we use different solution for OO language vs procedure language.

Considering X/Motif/Gnome, you always register handler for specific event.
The event dispatcher just search the event map. So you can use the same
event handler for different window types and different event types.

Hong

Re: Final, no really, Final draft: Conventions and Guidelines forPerl Source Code

[Sam Tregar]

On Thu, 30 Aug 2001, Simon Cozens wrote:

> That's not entirely relevant any more. Parrot has a semi-autonomous
> existence as a generic bytecode interpreter. We may be a long way
> from having a language spec, but we're pretty damned close to having
> a spec for the interpreter.

I look forward to reading it!

-sam

Re: Final, no really, Final draft: Conventions and Guidelines forPerl Source Code

[Uri Guttman]

> "ST" == Sam Tregar <[EMAIL PROTECTED]> writes:

  ST> On Thu, 30 Aug 2001, Uri Guttman wrote:
  >> we have very strong internal specs already that will support most
  >> anything larry throws at us. stuff such as the op code loop, async
  >> (file) i/o, events, etc, are all known to be needed so we can code them
  >> now that the design is firming up. we have the flexibility to support
  >> most anything with decent efficiency.

  ST> Where can I read this stong spec?  What I've seen so far is good,
  ST> but it hasn't imparted to me enough to be sure that it'll handle
  ST> anything Larry could desire.  Larry is more inventive than most.

  ST> What I've seen so far resembles a software CPU, which be analogy
  ST> should be able to do anything from run Quake III to compile Java.
  ST> Does that mean it's well-suited to compiling Perl?  I don't know -
  ST> I haven't seen enough of the design.

well, that is the spec. those of us working on it feel it will be fairly
fast and very flexible which are our two goals. dan has a prototype
working and those early numbers sound interesting if not real world.

as simon stated too, the interpeter will be separated from perl proper
as it is aimed to support other languages. who knows, maybe the others
will standardize on parrot and it will become the common backend for
multiple languages.

  >> some areas such as GC need more spec work as we don't know how the
  >> language will affect it (DESTROY, etc.).

  ST> Careful - Dan smacks people that use GC and DESTROY in the same
  ST> sentence.

i can duck. :) i meant that we will want some form of DESTROY and that
has been bandied about. but that can affect some aspects of GC at a
minimum. maybe not directly (which is good) but it is something to be
aware of.

uri

-- 
Uri Guttman  -  [EMAIL PROTECTED]  --  http://www.sysarch.com
SYStems ARCHitecture and Stem Development -- http://www.stemsystems.com
Search or Offer Perl Jobs  --  http://jobs.perl.org

Re: Final, no really, Final draft: Conventions and Guidelines for Perl Source Code

[Simon Cozens]

On Thu, Aug 30, 2001 at 01:40:15PM -0400, Sam Tregar wrote:
> What I've seen so far resembles a software CPU, which be analogy should be
> able to do anything from run Quake III to compile Java.  Does that mean
> it's well-suited to compiling Perl?

The interpreter is highly unsuited to *compiling* Perl. Compiling Perl
is a hard task which we can't do until Larry gives us the language spec.
But even if we do have a language spec, it's extremely difficuilt to
compile to a target that does not exist. So the priority for us now is
to make that target exist. Hence the need to start coding the
interpreter.

While it's not intended to be good at compilation, the interpreter is
going to behighly suited to running *any* kind of bytecode. There are a
bunch of reasons why I know it'll be flexible enough to run anything
Larry throws at us. For starters, we're taking all the techniques from
all the other interpreters we can find and working out both the
intersection and the union of them. We know what an interpreter needs to
do, and we know what a lot of languages need from their interpreter.

Secondly, I know the interpreter will be able to run anything Larry
throws at it for the paradoxical reason that the interpreter will know
*nothing* about what Larry's likely to throw at it. Does a real CPU
know whether it's running C or Java? Hell no. It runs whatever's in its
native machine code.

I could spend a lot of time justifying it to you here and now, or I
could spend the same time writing a detailed specification of the
interpreter interface. I think, to be honest, it might be more
productive for me to take the second option. However, I don't want you
to think I'm brushing your concerns aside; here's a quick sketch of what
I'm currently thinking.

The way Parrot will resolve the differences between languages
is to push off many of the operations onto the structures
which represent pieces of data inside the interpreter. That is
to say, the main loop of the Parrot interpreter will tell a
variable to increment itself; the type of the variable will
determine how that incrementation is done.

This will be achieved by a system of vtables attached to each
piece of data. Each piece of data will act like an object, and
vtables, which are structures of function pointers, represent the
methods the object can call. (Here it becomes important not to
confuse the object-like behaviour of the represented data with the
object system of the source language. When we talk about calling
methods on objects, we are referring to performing operations on
pieces of data as low-level as, say, an integer. We do not care
how the source language organises its object orientation.)

For instance, when a piece of data is told to increment
itself, it will locate the "increment" function pointer in its
vtable, and call the function on itself. This allows us to
keep the semantics of an operation separate between languages;
different languages will beget objects with different vtables.

In a sense, this is not dissimilar to the way the Python VM is
currently implemented; Python also allows for new types to be
implemented, with differing behaviour, simply by defining new
methods to go in the new type's vtable. However, Parrot's data
objects will differ from Python's in subtle ways - for
instance, they will have the ability to transform themselves
to a different type; they will not have a separate type
object, but directly contain a pointer to their vtable
methods.

As for opcodes, Parrot will allow the creation of user-defined
operations; a portion of the opcode table will be reserved for
builtins, with the rest available for user-defined ops. It is
hoped that subroutines will compile down to user-defined ops, and
that C functions from extension modules will be implemented as
user-defined ops. Within the bytecode, these user-defined ops will
be lexically scoped; each lexical scope will define an op table
mapping operations above the built-in watermark to relative
pointers in the fix-up section.

Opcodes may be overridden; Parrot will guarantee that overridable
ops will always be looked up in the op table before dispatch,
whereas non-overridable ops may be dispatched directly.

I hope this is enough to whet your appetite. There is more where that
came from, if I can be allowed time to finish. :)

Simon

Re: Final, no really, Final draft: Conventions and Guidelines forPerl Source Code

[Sam Tregar]

On Thu, 30 Aug 2001, Simon Cozens wrote:

> I could spend a lot of time justifying it to you here and now, or I
> could spend the same time writing a detailed specification of the
> interpreter interface. I think, to be honest, it might be more
> productive for me to take the second option.

I agree - go to it.  What you've written so far prompts as many questions
as it does provide answers, but I am reassured that a real spec is coming.

-sam

Re: Final, no really, Final draft: Conventions and Guidelines forPerl Source Code

[Sam Tregar]

On Wed, 29 Aug 2001, Simon Cozens wrote:

> It's almost time to start coding, people, almost.

Not to be an ass, but is it?  It seems like we're still a long way from
having a language spec.

-sam

Re: Final, no really, Final draft: Conventions and Guidelines for Perl Source Code

[Simon Cozens]

On Thu, Aug 30, 2001 at 01:25:37PM -0400, Sam Tregar wrote:
> On Wed, 29 Aug 2001, Simon Cozens wrote:
> > It's almost time to start coding, people, almost.
> Not to be an ass, but is it? 

Yes.

> It seems like we're still a long way from having a language spec.

That's not entirely relevant any more. Parrot has a semi-autonomous
existence as a generic bytecode interpreter. We may be a long way
from having a language spec, but we're pretty damned close to having
a spec for the interpreter.

(Now the Perl 6 compiler and plugins for it, I grant you, we'll have
to fill in later.)

Simon

Re: Final, no really, Final draft: Conventions and Guidelines forPerl Source Code

[Uri Guttman]

> "ST" == Sam Tregar <[EMAIL PROTECTED]> writes:

  ST> On Wed, 29 Aug 2001, Simon Cozens wrote:
  >> It's almost time to start coding, people, almost.

  ST> Not to be an ass, but is it?  It seems like we're still a long way from
  ST> having a language spec.

we have very strong internal specs already that will support most
anything larry throws at us. stuff such as the op code loop, async
(file) i/o, events, etc, are all known to be needed so we can code them
now that the design is firming up. we have the flexibility to support
most anything with decent efficiency. some areas such as GC need more
spec work as we don't know how the language will affect it (DESTROY,
etc.).

uri

-- 
Uri Guttman  -  [EMAIL PROTECTED]  --  http://www.sysarch.com
SYStems ARCHitecture and Stem Development -- http://www.stemsystems.com
Search or Offer Perl Jobs  --  http://jobs.perl.org

Re: Final, no really, Final draft: Conventions and Guidelines forPerl Source Code

[Sam Tregar]

On Thu, 30 Aug 2001, Uri Guttman wrote:

> we have very strong internal specs already that will support most
> anything larry throws at us. stuff such as the op code loop, async
> (file) i/o, events, etc, are all known to be needed so we can code them
> now that the design is firming up. we have the flexibility to support
> most anything with decent efficiency.

Where can I read this stong spec?  What I've seen so far is good, but it
hasn't imparted to me enough to be sure that it'll handle anything Larry
could desire.  Larry is more inventive than most.

What I've seen so far resembles a software CPU, which be analogy should be
able to do anything from run Quake III to compile Java.  Does that mean
it's well-suited to compiling Perl?  I don't know - I haven't seen enough
of the design.

> some areas such as GC need more spec work as we don't know how the
> language will affect it (DESTROY, etc.).

Careful - Dan smacks people that use GC and DESTROY in the same sentence.

-sam

Re: Configurators!

[Andy Dougherty]

On Sun, 26 Aug 2001, Nathan Torkington wrote:

> We're about to have a tarball of basic interpreter source (no compiler
> yet, only an assembler).  Dan's already run into portability problems,
> and once it comes out we're going to need to start working on the
> configuration and build system.

Could you give some examples?

For the time being, it might be useful to use the existing perl5
installation to bootstrap the perl6 build somehow.  Medium and long term,
that's a really terrible maintenance plan, but short term it's probably
not too bad.

I know one hope bandied about was a portable "microperl" that could be
used to write Configure.plx or some such.  However, the following entry in
perl5's Todo.micro

   - some of the uconfig.sh really needs to be probed (using cc) in
 buildtime: (uConfigure? :-) native datatype widths and endianness
 come to mind

makes me wonder how feasible that hope is.

Andy Dougherty  [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042

RE: CLOS multiple dispatch

[Hong Zhang]

> Because multimethods are inherently an OO technique. 
> 
You can say so, but I am not buying it very much.

> It doesn't. The multimethod consists of those variants that are currently
> loaded. 
> 
How do you define the currently loaded? If things are lazy loaded, the stuff
you expect has been loaded
may not have been loaded.

>> 2) If there is mismatch on more than one argument type, which
> argument
>> should be favored more than the others.
> 
> None of them. That's why Class::Multimethods doesn't use CLOS's awful
> "left-most argument first" resolution mechanism.
> 
So what is the next step. How do you define the next most-matched methods.

> That is simply not correct. There is a considerably body of research on
> efficient dispatching. Dan is already aware of this.
> 
I don't like this statement. If it was not an issue, why we need
considerable research on it.

> Multimethods elegantly solve a very hard problem in OO design: controlling
> the interactions of multiple objects fom multiple class hierarchies.
> They are not required often, but when they are needed (e.g. in the
> Quantum::Superpositions module), they are a *vastly* superior solution.
> 
We can not put every superior solution into one language. If we do, we don't
even need Perl 6, since all
solutions are included, there is no need to write program. It is just like
Fortran has built-in math functions,
but C does not. With optimized C compiler, we can achieve similar performace
with obviously more code.
Let's say C is only 80% of Fortran on math, I still don't see the reason to
put math into C language for
the last 20% of speed. It may be my personal preference. I am not going to
argue on this any more.

Hong

RE: CLOS multiple dispatch

[Damian Conway]

   > > It doesn't. The multimethod consists of those variants that are currently
   > > loaded. 
   > > 
   > How do you define the currently loaded? 

Accessible in the program's symbol table and registered with the multimethod
dispatcher.

   
   > >> 2) If there is mismatch on more than one argument type,
   > >>which argument should be favored more than the others.
   > > 
   > > None of them. That's why Class::Multimethods doesn't use CLOS's awful
   > > "left-most argument first" resolution mechanism.
   > > 
   > So what is the next step. How do you define the next most-matched methods.

http://dev.perl.org/rfc/256.html#Finding_the_nearest_multimetho


   > > That is simply not correct. There is a considerably body of research on
   > > efficient dispatching. Dan is already aware of this.
   > > 
   > I don't like this statement. If it was not an issue, why we need
   > considerable research on it.

We don't *need* it, we *have* it. People did that research so that 
efficient multiple dispatch would no longer *be* an issue.


   > We can not put every superior solution into one language.

But we *can* put multiple dispatch in, since it greatly extends an existing
superior solution (single dispatch).

Damian

Re: CLOS multiple dispatch

[Michael G Schwern]

On Thu, Aug 30, 2001 at 06:34:31PM -0700, Hong Zhang wrote:
> > None of them. That's why Class::Multimethods doesn't use CLOS's awful
> > "left-most argument first" resolution mechanism.
>
> So what is the next step. How do you define the next most-matched methods.

Please look at how Class::Multimethods works and what is described in
http://dev.perl.org/rfc/256.pod before continuing.  Play with
Class::Multimethods, because I believe that's pretty much RFC 256.


> > That is simply not correct. There is a considerably body of research on
> > efficient dispatching. Dan is already aware of this.
>
> I don't like this statement. If it was not an issue, why we need
> considerable research on it.

I think you misunderstood him.  Damian ment that people have *already*
done considerable research into efficient multimethod dispatch.  All
we (read 'Dan') have to do is read up on it.


> Let's say C is only 80% of Fortran on math, I still don't see the
> reason to put math into C language for the last 20% of speed. It may
> be my personal preference.

The difference in speed between a pure-perl multimethods
implementation and an in-core implementation should be considerable.

If you're curious, benchmark the existing Class::Multimethods module
against normal method calls.

-- 

Michael G. Schwern   <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl6 Quality Assurance <[EMAIL PROTECTED]>   Kwalitee Is Job One
I'm spanking my yacht.

Multiple-dispatch on functions

[Michael G Schwern]

Thinking about what Zhang was saying about multiple-dispatch not being
inherently OO.  I think he's sort of right.  Multiple-dispatch need
not be confined to method lookups.

foo();
foo($bar);
foo($baz);
foo($bar, $baz);

sub foo () : multi {
...
}

sub foo (Bar $bar) : multi {
...
}

sub foo (Baz $baz) : multi {
...
}

...etc...

Obviously, there would be no inheritance.  Otherwise, it's
just like multiple-dispatch where there's no superclass.

Handy, if it's not too hard to implement.


-- 

Michael G. Schwern   <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl6 Quality Assurance <[EMAIL PROTECTED]>   Kwalitee Is Job One
"Let's face it," said bearded Rusty Simmons, opening a can after the
race.  "This is a good excuse to drink some beer."  At 10:30 in the
morning?  "Well, it's past noon in Dublin," said teammate Mike
[Joseph] Schwern.  "It's our duty."
-- "Sure, and It's a Great Day for Irish Runners" 
   Newsday, Sunday, March 20, 1988

Re: CLOS multiple dispatch

[David L. Nicol]

Me wrote:

> I can imagine plausibly useful dispatch rulesets that do not involve
> comparing sums of inheritance distances. (Though this *is* all
> imagining as I haven't used multimethods/clos in about 10 years.)
> 
> I would also imagine that others see that summing inheritance
> distances may not be the only intelligent way to pick among
> candidates when a perfect fit is not available.

One stupid but simple system would be, take the best fit on
the first argument, then choose from among remaining variants for
second argument, repeat for all arguments.

Combined with an easy syntax for duplicating all possible calls
for purposes of matching on the second or nth argument, or at least
a tool for listing all the prototypes, for development purposes.

That could get ugly though.


dispatching a call with N typed arguments could be considered as
selecting a cell from a sparsely filled array in N-space.  In keeping
with the idea of virtual tables, the N-block could be completely filled
at routine registration time. Which means we would need a prototype
language that says which cells in N-space to take.  Maybe a parameter
to indicate "match strength" 


or multiple prototypes for the same routine:

sub handle
   (normal_window $w, resize_event $e)
   (contrived_resizing_window $w, event $e)
{
$w->set_size(e->get_size);
};

combined with a shorthand for generating lots of available prototypes

sub handle
   (*_window $w, kill_event $e)
{
$w->kill();
};


At some point during last year's discussions (possibly a year ago this
week, who knows) there was discussion of making the prototypes
match based on regular expression match against the names of the
types of the objects.  That would be a mechanistic approach to
implicitly filling the N-block.  I believe it was left out of rfc97
due to incompleteness of the specification.



 
> Even if the dispatcher is the heart of multimethods, perhaps it
> would be nice if it were convenient to replace the dispatcher
> in whole or part. 

If the dispatcher is drop-in replacable, what does its interface
look like?  How much information is it allowed to gether from the
source code?  Do we even want to support one specific one rather
than what we can do in '5 which is set up a special package
where multimethods live and have each one start off with its
dispatch routine?


multimethods::handle($w,$e);



-- 
   David Nicol 816.235.1187
   KAK OH CKA3AT "what he said"

Re: CLOS multiple dispatch

[David L. Nicol]

Hong Zhang wrote:

> 3) The multi dispatch is generally slow and complicated. Since it does
> not fit well with OO concept, it will just cause more confusion. Typically
> we use different solution for OO language vs procedure language.


In other words, how much do we want our language to set up for us
and how much do we want to do ourselves?



-- 
   David Nicol 816.235.1187
A long time ago, in a galaxy far far away...

Re: CLOS multiple dispatch

[Damian Conway]

Dan observed:

   > I hadn't considered having it as a global thing, just because I can see
   > class Foo wanting multimethods, and class Bar being fine with 'normal'
   > class hierarchy walking, and class Baz deciding it wants the automatic
   > redispatch form of method calling.
   > 
   > We could make it a global thing and have only a single way to dispatch, in
   > which case it would be lexically overridable, but that seems awfully
   > limiting...

I fully agree that per-class and per-object dispatch control is desirable.
But I was also proposing that the *default* dispatch mechanism be
user-selectable. Hence a global hook.

Damian

RE: CLOS multiple dispatch

[Damian Conway]

Hong wrote:

   > > Note that the handler that is selected depends on the *combination* of
   > > the types of the two arguments. And that the dispatcher understands
   > > the argument/parameter inheritance relationships and selects the most
   > > specific handler for each combination. For example, a MoveEvent sent to
   > > a FixedWindow causes a beep, but a MoveEvent sent to any other type of
   > > window is dispatched to the more-generic handle(Window $w, MoveEvent $e)
   > > subroutine, which causes it to move.
   > 
   > I believe this feature has some conflict with OO dispatch. In a pure
   > static procedure language, this can be nicely and easily done. I am not
   > if we really this for Perl.

We already have it in Perl (in the Class::Multimethods module). There's
no conflict with regular OO dispatch. In fact the two work quite well
together. Because multimethods are inherently an OO technique. 


   > 1) How do we find the method if the package is lazy loaded? The "sub"
   > can sit in some package that is irrelavent to the argument types. How
   > can runtime decide whether to use handle(Window $w, Event $e) or try
   > to load some 'magik' package, which happens to define 
   > handle(Window $w, FooEvent $e).

It doesn't. The multimethod consists of those variants that are currently
loaded. 


   > 2) If there is mismatch on more than one argument type, which argument
   > should be favored more than the others.

None of them. That's why Class::Multimethods doesn't use CLOS's awful
"left-most argument first" resolution mechanism.


   > 3) The multi dispatch is generally slow and complicated.

That is simply not correct. There is a considerably body of research on
efficient dispatching. Dan is already aware of this.
   

   > Since it does not fit well with OO concept

That is simply not correct. Multiple dispatch is fundamentally *only* an OO
concept. It is a generalization of the fundamental OO concept of single
dispatch.

   
   > it will just cause more confusion.

This *might* be correct but, since multimethods will be optional, it probably
won't matter. ;-)

   
   > Typically we use different solution for OO language vs procedure
   > language.

...one that is slower, uglier, and more error-prone. :-(

Multimethods elegantly solve a very hard problem in OO design: controlling
the interactions of multiple objects from multiple class hierarchies.
They are not required often, but when they are needed (e.g. in the
Quantum::Superpositions module), they are a *vastly* superior solution.

Damian

Re: Source/Program metadata from within a program

[Michael G Schwern]

On Fri, Aug 31, 2001 at 12:45:03AM -0400, Bryan C. Warnock wrote:
> Access to the source code.  

Already got that.  

use Fcntl qw(:seek);
seek DATA, 0, SEEK_SET;
@code = ;


> We're going to be carrying it around, unless we 
> strip it.  We might as well put it to good use within error messages and the 
> like.  If an error points me to foo:356, I want my DIE handler to dump the 
> code surrounding that.

> Compilation time.  For each of my compilation units, I would like to know 
> when it was compiled.  Compilation unit scoped. 

You can already do that.  Override CORE::GLOBAL::require/use/do.

Your overridden require/use/do can mark the time it was called *and*
remember the *DATA filehandles.  On an error, you can do:

use Fcntl qw(:seek);
$SIG{__DIE__} = sub {
my($pack, $file, $line) = caller;

if( my $data_fh = $DATA{$file} ) {
my $orig_pos = tell $data_fh;

seek $data_fh, 0, SEEK_SET;
my @code = <$data_fh>;

print STDERR @_;
print STDERR @code[$line-2..$line+2];

seek $data_fh, $orig_pos, SEEK_SET;
}

}

When will we be seeing the CPAN module for this?


-- 

Michael G. Schwern   <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl6 Quality Assurance <[EMAIL PROTECTED]>   Kwalitee Is Job One
I know you get this a lot, but what's an unholy fairy like you doing in a
mosque like this?

Re: Source/Program metadata from within a program

[Bryan C . Warnock]

On Friday 31 August 2001 01:13 am, Michael G Schwern wrote:
> On Fri, Aug 31, 2001 at 12:45:03AM -0400, Bryan C. Warnock wrote:
> > Access to the source code.
>
> Already got that.

Not if we don't have the source.  Or perhaps this will be the way we do it.  
Dunno.  Perl Bytecode has a section for storing the source code.  I was 
thinking more of that.

>
> > Compilation time.  For each of my compilation units, I would like to
> > know when it was compiled.  Compilation unit scoped.
>
> You can already do that.  Override CORE::GLOBAL::require/use/do.
>
> Your overridden require/use/do can mark the time it was called *and*
> remember the *DATA filehandles.  On an error, you can do:

Not called.  Compiled.  Once again, I'm thinking of pre-compiled bytecode 
modules.

>
> When will we be seeing the CPAN module for this?

Looks like you just wrote it.  :-)


-- 
Bryan C. Warnock
[EMAIL PROTECTED]

Re: Source/Program metadata from within a program

[Bryan C . Warnock]

On Friday 31 August 2001 01:13 am, Brent Dax wrote:
> # -Original Message-
> # From: Dave Storrs [mailto:[EMAIL PROTECTED]]
> # I'd also like to be able to access information on the
> # particular perl that
> # is running this program...e.g., does it support 64-bit nums,
> # what is the
> # endianness of the native numbers, does it support threads and
> # (if so) what
> # threading model (though this is probably a moot point in P6,
> # perhaps it
> # is something that could be included into 5.8.x).
>
> Can't this sort of thing be in Config.pm (or its equivalent)?  Since
> Parrot needs to know things like endian-ness and for reading precompiled
> bytecode anyway, we might as well make it convenient...

For the static information with the interpreter, yes, probably ~Config.pm.  
However, (once again thinking about precompiled bytecode), the appropriate 
static configuration info from the perl that compiled a particular unit may 
be nice, although most likely unnecessary.  Although, with the exception of 
endianess and native extensions, the bytecode is supposed to be the same.

-- 
Bryan C. Warnock
[EMAIL PROTECTED]

Re: Source/Program metadata from within a program

[Bryan C . Warnock]

On Friday 31 August 2001 01:13 am, Brent Dax wrote:
> Cool--I'd suggest a special $*CODE filehandle, to match $*DATA (that
> isn't going away, is it?).

IIRC, $*DATA is going away, in favor of something a little more 
Inline::File-ish - i.e., an arbitrary number of arbitrarily named 
pseudohandles.  But there's probably no reason that $*CODE couldn't 
specifically refer to the entire file.

-- 
Bryan C. Warnock
[EMAIL PROTECTED]

RE: Source/Program metadata from within a program

[Brent Dax]

# -Original Message-
# From: Michael G Schwern [mailto:[EMAIL PROTECTED]]
# Sent: Thursday, August 30, 2001 10:13 PM
# To: Bryan C. Warnock
# Cc: [EMAIL PROTECTED]
# Subject: Re: Source/Program metadata from within a program
#
#
# On Fri, Aug 31, 2001 at 12:45:03AM -0400, Bryan C. Warnock wrote:
# > Access to the source code.
#
# Already got that.
#
# use Fcntl qw(:seek);
# seek DATA, 0, SEEK_SET;
# @code = ;

IMHO, that's too hackish--just reading that doesn't make what you're
doing obvious.  An explicit $*CODE filehandle would make more sense to
the uninitiated.

--Brent Dax
[EMAIL PROTECTED]

"...and if the answers are inadequate, the pumpqueen will be overthrown
in a bloody coup by programmers flinging dead Java programs over the
walls with a trebuchet."

Re: Multiple-dispatch on functions

[Damian Conway]

   > Thinking about what Zhang was saying about multiple-dispatch not being
   > inherently OO.  I think he's sort of right.  Multiple-dispatch need
   > not be confined to method lookups.

True, but that doesn't make it non-OO ;-)


   > foo();
   > foo($bar);
   > foo($baz);
   > foo($bar, $baz);
   > 
   > sub foo () : multi { ... }
   > sub foo (Bar $bar) : multi { ... }
   > sub foo (Baz $baz) : multi { ... }

Yes. Ordinary subroutine overloading (like that offered by C++)
certainly does fall out as a happy side-effect of multiple dispatch
in dynamic languages.

For example, see:

http://dev.perl.org/rfc/256.html#Handling_built_in_types

But note that the *run-time* dispatch of these overloaded subroutines
is still critically important because of Perl's dynamic typing of values
within container data structures.

Damian

Re: Source/Program metadata from within a program

[Michael G Schwern]

On Thu, Aug 30, 2001 at 10:52:27PM -0700, Brent Dax wrote:
> # Already got that.
> #
> # use Fcntl qw(:seek);
> # seek DATA, 0, SEEK_SET;
> # @code = ;
> 
> IMHO, that's too hackish--just reading that doesn't make what you're
> doing obvious.  An explicit $*CODE filehandle would make more sense to
> the uninitiated.

sub my_code {
use Fcntl qw(:seek);
seek DATA, 0, SEEK_SET;
return ;
}

Stick that in a module, slap on some docs and you're all set.  Geeez,
that's what modules are for!

I thought we actually wanted to get something done, not sit around
saying "Everything will be perfect when Perl 6 comes!"


-- 

Michael G. Schwern   <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl6 Quality Assurance <[EMAIL PROTECTED]>   Kwalitee Is Job One
"Let's face it," said bearded Rusty Simmons, opening a can after the
race.  "This is a good excuse to drink some beer."  At 10:30 in the
morning?  "Well, it's past noon in Dublin," said teammate Mike
[Joseph] Schwern.  "It's our duty."
-- "Sure, and It's a Great Day for Irish Runners" 
   Newsday, Sunday, March 20, 1988

Source/Program metadata from within a program

[Bryan C . Warnock]

Many of Perl 5's global variables are becoming properties of various Perl 6 
entities - $. and $/ for input filehandles, for instance.

There is still a large subset of global information that describes the 
program itself - some of which has been called for removal (or at least 
burial within some module) - plus more information that we *could* access, 
because we would be carrying it around.

The former being runtime information like..
$] $0 $$ $< $> $( $) $^C $^D $^H $^M $^O $^S $^T $^V $^W $^X

Will this remain global?  Will we have an introspective module that we can 
use to access this information?

In either case, there is some more information that we may or may not have, 
that it would be nice to be able to have access to  I will refrain from 
naming them, as noone ever likes how I name things

Knowledge of the complete (relative) path to each component of a perl 
program, as it was loaded.  For example, within Foo.pm as 
/usr/lib/perl6/Foo_v1_by_whomever/Foo.pm (from the @INC lookup).  'perl 
../foo' as '../foo', regardless of what games I play with $0.  If we're 
going to have multiple versions of modules, I would like to be able to 
report specifically which one it really is.  If we could realpath() it, 
that'd be even better, but that's not for the builtins.  File scoped.
Most likely, you'll want access to the rest of the module's metadata, too.
(If you specified wildcards, for instance.)

Knowledge of whether a file was the perl program invoked, or if it were 
included from another file.  For example, running 'perl foo' would have a 
true value for the file 'foo', but a false value for Foo.pm, which it may 
'do', 'use', or 'require'.  File scoped.

Access to the source code.  We're going to be carrying it around, unless we 
strip it.  We might as well put it to good use within error messages and the 
like.  If an error points me to foo:356, I want my DIE handler to dump the 
code surrounding that.  Useful for when I'm on a server, far from the source 
code I didn't deploy with the compiled exectuables.  This would more or less 
be how a remote debug would have to work anyway.

Compilation time.  For each of my compilation units, I would like to know 
when it was compiled.  Compilation unit scoped. 

-- 
Bryan C. Warnock
[EMAIL PROTECTED]

Re: Source/Program metadata from within a program

[Dave Storrs]

On Fri, 31 Aug 2001, Bryan C. Warnock wrote:

> Access to the source code.  

Particularly comments and POD.

I'd also like to be able to access information on the particular perl that
is running this program...e.g., does it support 64-bit nums, what is the
endianness of the native numbers, does it support threads and (if so) what
threading model (though this is probably a moot point in P6, perhaps it
is something that could be included into 5.8.x).


Dave Storrs

RE: Source/Program metadata from within a program

[Brent Dax]

# -Original Message-
# From: Dave Storrs [mailto:[EMAIL PROTECTED]]
# Sent: Thursday, August 30, 2001 9:59 PM
# To: The Perl6 Language List
# Subject: Re: Source/Program metadata from within a program
#
# On Fri, 31 Aug 2001, Bryan C. Warnock wrote:
#
# > Access to the source code.
#
#   Particularly comments and POD.

Cool--I'd suggest a special $*CODE filehandle, to match $*DATA (that
isn't going away, is it?).

# I'd also like to be able to access information on the
# particular perl that
# is running this program...e.g., does it support 64-bit nums,
# what is the
# endianness of the native numbers, does it support threads and
# (if so) what
# threading model (though this is probably a moot point in P6,
# perhaps it
# is something that could be included into 5.8.x).

Can't this sort of thing be in Config.pm (or its equivalent)?  Since
Parrot needs to know things like endian-ness and for reading precompiled
bytecode anyway, we might as well make it convenient...

--Brent Dax
[EMAIL PROTECTED]

"...and if the answers are inadequate, the pumpqueen will be overthrown
in a bloody coup by programmers flinging dead Java programs over the
walls with a trebuchet."