Some questions:

-----

Can we get an AUTOCLASS/AUTOCLASSDEF hook pair?

-----

How does one create a class with a hyphen in the middle of it? If I say:

use Foo-Bar;

will it complain about not finding a Bar version of Foo? Would I instead
need to say:

use 'Foo-Bar';
use Foo\-Bar;
use ('Foo-Bar');
$x = 'Foo-Bar'; use $x;

btw, that last one would be really handy sometimes, but for other reasons.

-----

If we do:

use Dog-1.2.3;
use Dog-2.0.1;
my Dog $spot;

What do we get? Okay, I know, an error message, but is it on line 2 or
line 3? Can we instead do something like:

use Dog-1.2.3;
use Dog-2.0.1 is rename(newDog);
my newDog $spot;

-----

There needs to be some definition of what happens when more than one
module matches a given wildcard in 'use'.

Something like:
   1. Throw a warning
   2. Pick the highest version, then the earliest source in the alphabet

of course, there should be a way to flag it to work in other ways, so
some project could have a standard:

use ($^name ~~ /^Project::/)-(Any)-TPFBundle;

meant to include all the modules made thus far. And yes, I can come up
with times when this would be useful.

-----

I see some utility in having an optional sub-source or version code thingy.
Something like:

use Dog-(Any)-(Any)-Stable;
use Canine-(Any)-(Any)-Development;

-----

Can we get a hook that gets called when 'use' fails to find module
locally? I see potential for:

use AutoCPAN;
use Some::Module::Not::Currently::Loaded;

hmm. that doesn't work, since you typically won't be including the cpan
author code if you don't have to.

CPAN, or some other public source would be a definate security risk, and
thus to be discouraged, but it should be possible to write the thing.
I've heard of sites who had massively distributed mod_perl servers,
where all the code past a simple stub was stored in a central RDBMS.
Made releases and version control much nicer.

-----

By saying

#!/usr/bin/perl6

forces Perl 6, I assume you mean : "The compiler sees /:i ^#! .* perl6/
on the first line".

-----

-- Rod Adams

: Can we get an AUTOCLASS/AUTOCLASSDEF hook pair?

Considering a class is just a variable in another symbol table, seems
like an AUTOVAR in the container might cover it.

: How does one create a class with a hyphen in the middle of it?

Why would you want to?  Perl 5 doesn't allow it, and I sincerely doubt
Parrot is going to incorporate a bunch of Lisp libraries any time soon.

; If I say:
:
: use Foo-Bar;
:
: will it complain about not finding a Bar version of Foo?

It'd probably complain that Bar doesn't look anything like a version number.

: Would I instead need to say:
:
: use 'Foo-Bar';
: use Foo\-Bar;
: use ('Foo-Bar');
: $x = 'Foo-Bar'; use $x;
:
: btw, that last one would be really handy sometimes, but for other reasons.

All symbolic indirection is done with ::($expr) in Perl 6, so it'd be

    use ::('Foo-Bar')

: If we do:
:
: use Dog-1.2.3;
: use Dog-2.0.1;
: my Dog $spot;
:
: What do we get? Okay, I know, an error message, but is it on line 2 or
: line 3?

Presuming we add some way to do aliasing, line 2 would give an error.

: Can we instead do something like:
:
: use Dog-1.2.3;
: use Dog-2.0.1 is rename(newDog);
: my newDog $spot;

More likely something on the order of

    module newDog ::= (use Dog-2.0.1);

where it's only a "use" in a void context that implicitly uses the same
short name as the alias.  But like I said, it's not even clear that the
pseudo listop syntax of "use" is the right way to handle this.  Maybe it's
just an "isa"-like thing:

    my module newDog is Dog-2.0.1;

or maybe it's more like a role:

    my module newDog does Dog-2.0.1;

But maybe it's something else again that we just haven't thought of yet.

: There needs to be some definition of what happens when more than one
: module matches a given wildcard in 'use'.
:
: Something like:
:   1. Throw a warning
:   2. Pick the highest version, then the earliest source in the alphabet

I think you're assuming version numbers contain alphabetics.  I'd like to
stay away from that if possible.  But I think #2 is far and away the
most common intent with a wildcard on version numbers.  I don't know what
the pecking order should be among authors, but as someone who has suffered
from being a W, it's not going to be alphabetical.  :-)

My wife didn't believe me till she married me and moved from B to W.

Maybe #1 is a suitable response for multiple matching authors.  Or maybe
it should just pick one randomly to keep people honest.

: of course, there should be a way to flag it to work in other ways, so
: some project could have a standard:
:
: use ($^name ~~ /^Project::/)-(Any)-TPFBundle;
:
: meant to include all the modules made thus far. And yes, I can come up
: with times when this would be useful.

That sort of thing should be hidden in a metamodule.  In any event, it
doesn't give a good name to alias to.  (And placeholders only work inside
closures.)

: I see some utility in having an optional sub-source or version code thingy.
: Something like:
:
: use Dog-(Any)-(Any)-Stable;
: use Canine-(Any)-(Any)-Development;

Doesn't seem like a strong case to me.  At some point we transition to
ordinary adverbials to specify optional metadata.

: Can we get a hook that gets called when 'use' fails to find module
: locally? I see potential for:
:
: use AutoCPAN;
: use Some::Module::Not::Currently::Loaded;
:
: hmm. that doesn't work, since you typically won't be including the cpan
: author code if you don't have to.

Perl 6 will give you enough rope to shoot yourself in the foot.

: CPAN, or some other public source would be a definate security risk, and
: thus to be discouraged, but it should be possible to write the thing.
: I've heard of sites who had massively distributed mod_perl servers,
: where all the code past a simple stub was stored in a central RDBMS.
: Made releases and version control much nicer.

All is fair if you predeclare.

: By saying
:
: #!/usr/bin/perl6
:
: forces Perl 6, I assume you mean : "The compiler sees /:i ^#! .* perl6/
: on the first line".

Yes.  But that presumes anything wanting to run ponie doesn't invoke
it by feeding Perl 5 code to /usr/bin/perl6.  Presuming /usr/bin/perl
is reserved for the current Perl 5 engine, we either have to provide
an entry like /usr/bin/ponie, or say that /usr/bin/perl6 doesn't actually
force Perl 6.

Which is perhaps another argument for finding a different keyword than "use".

Larry

I guess I don't understand enough of how P6 is being built, but wouldn't
a similar argument hold for AUTOMETH and AUTOSUB?

Very nice.

I'm largely indifferent to the exact syntax involved, as long as I have
some way to loading two different versions of the same module, and can
then differentiate between them in my code. Possible reasons for loading
two versions of the same thing:

1) Retrograde testing. You just built a new version, and you want to
have the two versions running side by side through the test cases,
without having to kick off a new instance.

2) The nifty new version has a whiz-bang function you really need, but
in the process of upgrading, it broke some other whiz-bang function.

3) The two really are not the same thing, they were just given the same
name.

There are some separate benefits of module aliasing, aside from loading
like-named modules, to consider:

1) The module is named something like
"AudioFile::Info::Ogg::Vorbis::Header::PurePerl", and you'd rather not
type it more than once.

2) You just changed your entire module naming scheme, and want a stop
gap measure for all you code that's still referring to the old names.

Nope, I wasn't. I was using the word "source" where you were saying
"author".

As one with a last name starting with "ADA", I can't say I've noticed
any problems with alphabetical. =).

As for picking "randomly", I think a more deterministic method would be
in order. But something that can't be easily abused by naming it
"____0000AAAA". How about the following rules for multiple wildcard matches:

1) If the version numbers differ, pick the highest.
2) else, throw a warning (error if strictures), AND
2a) if one is in a directory earlier in @INC than the other(s), use it.
(Allow users to have a local copy override a global one).
2b) else, pick the one with the lowest CRC32 value of the Author

metamodule. hmm. That brings us back to Aaron Sherman's topic of
re-exportation.
How does one make a metamodule which uses other modules, and has those
modules' exports available to metamodule's caller, as if the caller had
instead called all of those modules in addition to the metamodule?

Grr. My web browser used a font that does not adequately distinguish
between braces and parens, so I didn't see the difference when reading it.

So one could make a call such as:

Dog.pm:

module Dog-1.2.5-AdamsR is Stable;

...

main.pl:

use Dog is Stable;

I can't say I've been able to keep all the is/but/has/: in my head for
any duration. It always makes sense when I study it, but without use it
fades.

I would think

/usr/bin/perl6    forces perl6
/usr/bin/ponie    forces ponie
/usr/bin/perl5p   alias for ponie, as some sites might find the term
"ponie" too removed from "perl"
/usr/bin/perl    uses other rules to detect ponie vs perl6.

The easiest, of course, is "Use". But that's likely the wrong answer.
The next most obvious ones are "import", "include", and "load".

playing with a thesaurus, I see:

acquire
add
adopt
admit
apply
embrace
employ
exploit
fetch
grab
introduce
involve

But overall, I think staying with "use" is best. Giving people a ponie
to play with in their transition to p6 is, I think, enough. The shebang
line should provide more than enough opportunity to declare what you
want, even if you have to resort to the -*- tricks to get there. We
would just have to say that as far as multiple option on the shebang
line goes, the latest one specified wins. (to help people on weird
systems where they might have to call perl6 to get ponie.

-- Rod Adams

:
: >On Tue, Nov 09, 2004 at 09:18:47PM -0600, Rod Adams wrote:
: >: Can we get an AUTOCLASS/AUTOCLASSDEF hook pair?
: >
: >Considering a class is just a variable in another symbol table, seems
: >like an AUTOVAR in the container might cover it.
: >
: >
:
: I guess I don't understand enough of how P6 is being built, but wouldn't
: a similar argument hold for AUTOMETH and AUTOSUB?

I don't think so--those have to interact with a dispatcher in addition
to ordinary name lookup.  But maybe AUTOVAR should be split up by
variable type.  The whole autoloading design is still pretty handwavy.

: I'm largely indifferent to the exact syntax involved, as long as I have
: some way to loading two different versions of the same module, and can
: then differentiate between them in my code. Possible reasons for loading
: two versions of the same thing:
:
: 1) Retrograde testing. You just built a new version, and you want to
: have the two versions running side by side through the test cases,
: without having to kick off a new instance.
:
: 2) The nifty new version has a whiz-bang function you really need, but
: in the process of upgrading, it broke some other whiz-bang function.
:
: 3) The two really are not the same thing, they were just given the same
: name.
:
:
: There are some separate benefits of module aliasing, aside from loading
: like-named modules, to consider:
:
: 1) The module is named something like
: "AudioFile::Info::Ogg::Vorbis::Header::PurePerl", and you'd rather not
: type it more than once.
:
: 2) You just changed your entire module naming scheme, and want a stop
: gap measure for all you code that's still referring to the old names.

You don't have to convince me of that.  I've already put in aliasing
so we can have short names for versioned modules.  We just need to
give the user a little more control of the actual aliasing.

: As one with a last name starting with "ADA", I can't say I've noticed
: any problems with alphabetical. =).

We could go with reverse alphabetical.  :P

: As for picking "randomly", I think a more deterministic method would be
: in order.

Sorry, I should have put another smiley on that, but I was running low...

: But something that can't be easily abused by naming it
: "____0000AAAA". How about the following rules for multiple wildcard matches:
:
: 1) If the version numbers differ, pick the highest.
: 2) else, throw a warning (error if strictures), AND
: 2a) if one is in a directory earlier in @INC than the other(s), use it.
: (Allow users to have a local copy override a global one).

Though bear in mind that we're totally restructuring how libraries work
so that we can have a given module visible to multiple versions of perl
by default.  Rather than probing directories directly, we're probably searching
some kind of stupid databasish thing.  (But that stupid databasish thing
may well be built or selected based on your current @INC settings, since
we do have be able to let people have local policy somehow or other.)

: 2b) else, pick the one with the lowest CRC32 value of the Author

The problem with that is that people will intentionally sign up for
author ids that have low hashed values.  I'd rather say that we die
on ambiguity, but ambiguity can be resolved by one module claiming
it's better than the other, so there's a partial ordering available
via the metadata.  One would have to die on partial ordering loops,
of course.  Probably we detect any such loop at installation time in
the main library, and in fact we could detect ties at that point and
make the installer pick who should win.

: metamodule. hmm. That brings us back to Aaron Sherman's topic of
: re-exportation.
: How does one make a metamodule which uses other modules, and has those
: modules' exports available to metamodule's caller, as if the caller had
: instead called all of those modules in addition to the metamodule?

Maybe it's just

    module MyPolicy is meta {
        use strict;
        use warnings;
        use fatal;
    }

or

    module MyPolicy {
        meta strict;
        meta warnings;
        meta fatal;
    }

or some such.

: So one could make a call such as:
:
: Dog.pm:
:
: module Dog-1.2.5-AdamsR is Stable;
:
: ...
:
:
: main.pl:
:
: use Dog is Stable;

That would only work if "is" bound to the class name, which is a bit odd.
The current "use" syntax is pretty general, but it doesn't map well to
Perl 6 declaration syntax.

: I would think
:
: /usr/bin/perl6    forces perl6
: /usr/bin/ponie    forces ponie
: /usr/bin/perl5p   alias for ponie, as some sites might find the term
: "ponie" too removed from "perl"
: /usr/bin/perl    uses other rules to detect ponie vs perl6.

But note that you're assuming with that last one that /usr/bin/perl
isn't the current Perl 5 interpreter.  I'm not sure that's a valid
assumption any time soon.

: But overall, I think staying with "use" is best. Giving people a ponie
: to play with in their transition to p6 is, I think, enough. The shebang
: line should provide more than enough opportunity to declare what you
: want, even if you have to resort to the -*- tricks to get there. We
: would just have to say that as far as multiple option on the shebang
: line goes, the latest one specified wins. (to help people on weird
: systems where they might have to call perl6 to get ponie.

Well, for sure you'll end up on back on the ponie if you feed a
"use 5" to perl6.

Larry

Rod wasn't necessarily presuming that /usr/bin/perl would _commonly_ be
the new Perl interpreter; but if somebody _does_ set up a computer in
which that was the case, it ought to do something and preferably DTRT.

But I'm guessing there's nothing special about the name /usr/bin/perl,
and that invoking the interpreter by any name that isn't perl6 or any
other declared 'special' name goes for the behaviour you explained of
assuming Perl 5 until it encounters one of the constructs such as a bare
C<my;> that persuade it otherwise.

Smylers