syntax for accessing multiple versions of a module
Nicholas Clark
Perl 6 will be able to load more than one version of the "same" module.
As I understand it, this would let you have more than one version of
"DBI" loaded in the same interpreter, and also have DBI written by Tim Bunce
and "DBI" written by A.U.Thor in the same interpreter.
Is the syntax for accessing different versions of the same module from Perl
nailed down yet?
Specifically this is in reference to wondering if the multiple module trick
would actually be possible in perl 5:
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2005-10/msg00585.html
and how to do something functionally like:
my $foo = DBI(1.38)->new();
my $bar = DBI(1.40)->new();
or whatever to distinguish which you wanted to call a class method on.
Nicholas Clark
Juerd
> my $foo = DBI(1.38)->new();
> my $bar = DBI(1.40)->new();
I like this syntax, and have a somewhat relevant question: can a module
be aliased entirely, including all its subclasses/-roles/-.*?
Something like
use DBI as RealDBI;
use MyDBI as DBI;
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Rob Kinyon
> Nicholas Clark skribis 2005-10-18 22:41 (+0100):
> > my $foo = DBI(1.38)->new();
> > my $bar = DBI(1.40)->new();
>
> I like this syntax, and have a somewhat relevant question: can a module
> be aliased entirely, including all its subclasses/-roles/-.*?
>
> Something like
>
> use DBI as RealDBI;
> use MyDBI as DBI;
Since a Package or a Module can be a scalar, there shouldn't be a
reason why this isn't possible.
Rob
Stevan Little
This is addressed in S11, here is a link:
http://search.cpan.org/~ingy/Perl6-Bible/lib/Perl6/Bible/S11.pod
To summarize, the syntax to load the modules is:
use Dog-1.2.1;
While the syntax to create a specific version of a module is:
my Dog-1.3.4-cpan:JRANDOM $spot .= new("woof");
I addresses the class creation syntax partially in the initial
version of the Metamodel prototype, which was built in p5. I
basically just aliased the package with the long name (%{"Dog-1.3.4-
cpan:JRANDOM::"} = %{"Dog::"}). However this does no good for loading
of modules.
I have been giving this some though though, and here is a rough
sketch of what I have come up with so far.
Any module loaded is stored into *:: (or the p5 *main::) as the
longest name given. This means that if I do this:
use Dog-1.2.1-cpan:JRANDOM;
Then I have an entry for "Dog-1.2.1-cpan:JRANDOM" in the symbol
table. If, further along in the compilation process, I encounter
another Dog, such as:
use Dog-0.0.2-cpan:LWALL;
Then this is added as "Dog-0.0.2-cpan:LWALL" into the main symbol
table. Then once the compilation process is complete, I traverse the
symbol table hierarchy collecting all the names. Any duplicate short
names (Dog) are noted for later. Once I have collected all the names,
I build all my aliases.
So if I find:
use Cat-0.0.1-cpan:JRANDOM;
only once, I build an alias for (at a minimum) "Cat" and "Cat-0.0.1".
For my duplicates, the table would look something like this I think:
Dog => Dog-1.2.1-cpan:JRANDOM
Dog-1.2.1 => Dog-1.2.1-cpan:JRANDOM
Dog-0.0.2 => Dog-0.0.2-cpan:LWALL
We are explictly giving the preference to the later version number (I
think we discussed this at the Toronto hackathon).
Another school of thought would be that "Dog" alone would be
considered ambiguious and so we would just alias far enough to be
clear, like this:
Dog => Ambiguity Error!
Dog-1.2.1 => Dog-1.2.1-cpan:JRANDOM
Dog-0.0.2 => Dog-0.0.2-cpan:LWALL
Of course, this means that if I also load "Dog-1.2.1-cpan:LWALL" that
the table looks like this:
Dog => Ambiguity Error!
Dog-1.2.1 => Ambiguity Error!
Dog-0.0.2 => Dog-0.0.2-cpan:LWALL
And the user is now forced to add the cpan id to get Dog-1.2.1. I am
not sure how strict @Larry wants this to be.
I have been meaning to do some kind of p5 prototype of this, I can
push it up the TODO list if it would help you.
Stevan
Rob Kinyon
> considered ambiguious and so we would just alias far enough to be
> clear, like this:
>
> Dog => Ambiguity Error!
> Dog-1.2.1 => Dog-1.2.1-cpan:JRANDOM
> Dog-0.0.2 => Dog-0.0.2-cpan:LWALL
>
> Of course, this means that if I also load "Dog-1.2.1-cpan:LWALL" that
> the table looks like this:
>
> Dog => Ambiguity Error!
> Dog-1.2.1 => Ambiguity Error!
> Dog-0.0.2 => Dog-0.0.2-cpan:LWALL
>
> And the user is now forced to add the cpan id to get Dog-1.2.1. I am
> not sure how strict @Larry wants this to be.
NB: Dog-*-cpan:LWALL and Dog-*-cpan:JRANDOM, as well as *-*-cpan:LWALL
are also needed for entry into the mix because if there's only one
module loaded that is signed by cpan:LWALL, that should be sufficient
disambiguation for the parser. (How maintainable that is, I'll leave
as an exercise for the reader.)
Rob
Stevan Little
On Oct 18, 2005, at 11:15 PM, Rob Kinyon wrote:
> NB: Dog-*-cpan:LWALL and Dog-*-cpan:JRANDOM, as well as *-*-cpan:LWALL
> are also needed for entry into the mix because if there's only one
> module loaded that is signed by cpan:LWALL, that should be sufficient
> disambiguation for the parser. (How maintainable that is, I'll leave
> as an exercise for the reader.)
True, S11 does allow for some pattern matching on the version number
and authority (cpan-id/url/email), as well as ranges for the version
numbers. However, it seems to me that this is only for loading of
modules, and that once the module is loaded, it is expected they will
use a less ambiguous class name. Or at least I hope that is how it
will work ;)
Stevan
Larry Wall
: Then this is added as "Dog-0.0.2-cpan:LWALL" into the main symbol
: symbol table hierarchy collecting all the names. Any duplicate short
: names (Dog) are noted for later. Once I have collected all the names,
: I build all my aliases.
:
: So if I find:
:
: use Cat-0.0.1-cpan:JRANDOM;
:
: only once, I build an alias for (at a minimum) "Cat" and "Cat-0.0.1".
But you have to have the aliases there for correct parsing. Otherwise
"Cat" is a bareword, which is illegal. Of course, you can add the
alias without deciding what to bind it to. In fact, within a method,
we require "Cat" to be considered a virtual name, so if a derived
class uses a different Cat, it means that one instead for this object.
: For my duplicates, the table would look something like this I think:
:
: Dog => Dog-1.2.1-cpan:JRANDOM
: Dog-1.2.1 => Dog-1.2.1-cpan:JRANDOM
: Dog-0.0.2 => Dog-0.0.2-cpan:LWALL
:
: We are explictly giving the preference to the later version number (I
: think we discussed this at the Toronto hackathon).
Hmm, don't remember that. But I have a bad memory.
: Another school of thought would be that "Dog" alone would be
: considered ambiguious and so we would just alias far enough to be
: clear, like this:
:
: Dog => Ambiguity Error!
: Dog-1.2.1 => Dog-1.2.1-cpan:JRANDOM
: Dog-0.0.2 => Dog-0.0.2-cpan:LWALL
:
: Of course, this means that if I also load "Dog-1.2.1-cpan:LWALL" that
: the table looks like this:
:
: Dog => Ambiguity Error!
: Dog-1.2.1 => Ambiguity Error!
: Dog-0.0.2 => Dog-0.0.2-cpan:LWALL
:
: And the user is now forced to add the cpan id to get Dog-1.2.1. I am
: not sure how strict @Larry wants this to be.
I think $Larry wants to be strict on this, at least this week. If you're
using two different versions explicitly within the same scope, you should
probably be required to alias one of them. The main purpose of version
co-existence is for different modules to use different versions, not
the same module. I think using two different versions from the same
module is going to be relatively rare.
Larry
Ruud H.G. van Tol
> I think using two different versions from the same
> module is going to be relatively rare.
For dealing with two generations at the same time, like with
conversions: in stead of designing and applying a patch (SQL's ALTER
COLUMN, etc.), create a new dataset and let the old information pour in.
--
Grtz, Ruud
Stevan Little
On Oct 19, 2005, at 4:10 AM, Larry Wall wrote:
> On Tue, Oct 18, 2005 at 07:38:19PM -0400, Stevan Little wrote:
> : Then this is added as "Dog-0.0.2-cpan:LWALL" into the main symbol
> : table. Then once the compilation process is complete, I traverse the
> : symbol table hierarchy collecting all the names. Any duplicate short
> : names (Dog) are noted for later. Once I have collected all the
> names,
> : I build all my aliases.
> :
> : So if I find:
> :
> : use Cat-0.0.1-cpan:JRANDOM;
> :
> : only once, I build an alias for (at a minimum) "Cat" and
> "Cat-0.0.1".
>
> But you have to have the aliases there for correct parsing. Otherwise
> "Cat" is a bareword, which is illegal. Of course, you can add the
> alias without deciding what to bind it to. In fact, within a method,
> we require "Cat" to be considered a virtual name, so if a derived
> class uses a different Cat, it means that one instead for this object.
I suppose this could be done earlier in the compilation process then,
possibly we can make assumptions along the way and alias short names
immediately, only to retract the alias later if we see something that
conflicts. Assuming we do not encounter any user-level aliasing, I
think this would probably be okay.
However, this brings up an issue I was thinking about. Take this code
for instance:
use Cat-0.0.1;
use PetStore;
my Cat $kitty .= new();
--- in PetStore.pm ---
use Dog;
use Cat-0.0.5;
Which Cat is used? I can see several options:
1) Cat-0.0.1 is used since it is in the local scope, so clearly the
users choice.
2) Cat-0.0.5 is used since it is loaded after Cat-0.0.1.
3) An Ambiguity error is thrown because "Cat" is not specific enough.
Any option other than 1 requires the user to know what is going on
within PetStore.
> : For my duplicates, the table would look something like this I think:
> :
> : Dog => Dog-1.2.1-cpan:JRANDOM
> : Dog-1.2.1 => Dog-1.2.1-cpan:JRANDOM
> : Dog-0.0.2 => Dog-0.0.2-cpan:LWALL
> :
> : We are explictly giving the preference to the later version
> number (I
> : think we discussed this at the Toronto hackathon).
>
> Hmm, don't remember that. But I have a bad memory.
To be honest, I am not sure who I discussed it with, it might have
been autrijus. Either way it was in the early days of the hackathon,
and being a not-so-exciting topic, it was quickly forgotten about for
much cooler topics :)
To be honest, I don't really like this approach anyway.
> : Another school of thought would be that "Dog" alone would be
> : considered ambiguious and so we would just alias far enough to be
> : clear, like this:
> :
> : Dog => Ambiguity Error!
> : Dog-1.2.1 => Dog-1.2.1-cpan:JRANDOM
> : Dog-0.0.2 => Dog-0.0.2-cpan:LWALL
> :
> : Of course, this means that if I also load "Dog-1.2.1-cpan:LWALL"
> that
> : the table looks like this:
> :
> : Dog => Ambiguity Error!
> : Dog-1.2.1 => Ambiguity Error!
> : Dog-0.0.2 => Dog-0.0.2-cpan:LWALL
> :
> : And the user is now forced to add the cpan id to get Dog-1.2.1. I am
> : not sure how strict @Larry wants this to be.
>
> I think $Larry wants to be strict on this, at least this week.
Horray!
> If you're using two different versions explicitly within the same
> scope, you should
> probably be required to alias one of them. The main purpose of
> version
> co-existence is for different modules to use different versions, not
> the same module. I think using two different versions from the same
> module is going to be relatively rare.
Well, the first thing that comes to mind is that you could create a
"best-of-both-worlds" proxy object/module. Say some insane CPAN
developer radically changes an API, some of the changes make senses,
some of the changes clearly illustrate the developers insanity. It
might be useful to be able to create some kind of mix-up of the two
module versions in which you alias part of each API (assuming they
can co-exist peacefully that is).
Sure it's an out-on-the-edge case, but I could see some possible
usefulness.
Stevan
Larry Wall
: Larry Wall:
Yes, that's the use case I was thinking of. But I think version collisions
will happen much more often by accident, when two different modules use
different versions of the same module.
Larry
Jonathan Scott Duff
> However, this brings up an issue I was thinking about. Take this code
> for instance:
>
> use Cat-0.0.1;
> use PetStore;
>
> my Cat $kitty .= new();
>
> --- in PetStore.pm ---
>
> use Dog;
> use Cat-0.0.5;
>
> Which Cat is used? I can see several options:
>
> 1) Cat-0.0.1 is used since it is in the local scope, so clearly the
> users choice.
>
> 2) Cat-0.0.5 is used since it is loaded after Cat-0.0.1.
>
> 3) An Ambiguity error is thrown because "Cat" is not specific enough.
I would be _highly_ surprised if my $kitty wasn't a Cat-0.0.1
(assuming these auto aliases happen). Which Cat is available to the
programmer is a lexical property that shouldn't be invalidated because
some other module decided to use a different Cat. That would *so* be
action at a distance.
-Scott
--
Jonathan Scott Duff
du...@pobox.com
Larry Wall
: >On Tue, Oct 18, 2005 at 07:38:19PM -0400, Stevan Little wrote:
: >: Then this is added as "Dog-0.0.2-cpan:LWALL" into the main symbol
: >: table. Then once the compilation process is complete, I traverse the
: >: symbol table hierarchy collecting all the names. Any duplicate short
: >: names (Dog) are noted for later. Once I have collected all the
: >names,
: >: I build all my aliases.
: >:
: >: So if I find:
: >:
: >: use Cat-0.0.1-cpan:JRANDOM;
: >:
: >: only once, I build an alias for (at a minimum) "Cat" and
: >"Cat-0.0.1".
: >
: >But you have to have the aliases there for correct parsing. Otherwise
: >"Cat" is a bareword, which is illegal. Of course, you can add the
: >alias without deciding what to bind it to. In fact, within a method,
: >we require "Cat" to be considered a virtual name, so if a derived
: >class uses a different Cat, it means that one instead for this object.
:
: I suppose this could be done earlier in the compilation process then,
: possibly we can make assumptions along the way and alias short names
: immediately, only to retract the alias later if we see something that
: conflicts. Assuming we do not encounter any user-level aliasing, I
: think this would probably be okay.
Yes, especially if the result of a collision is somewhat fatal, so we
don't really have to try to undo anything. Another reason for taking
the strict line.
: However, this brings up an issue I was thinking about. Take this code
: for instance:
:
: use Cat-0.0.1;
: use PetStore;
:
: my Cat $kitty .= new();
:
: --- in PetStore.pm ---
:
: use Dog;
: use Cat-0.0.5;
:
: Which Cat is used? I can see several options:
They alias Cat differently in their lexical scope. $kitty is a version 0.0.1
kitty. If $kitty is is passed into PetStore, methods on it still call
into Cat-0.0.1. If PetStore makes a new cat, it's a 0.0.5 cat. Whether
different versions of cat are interconvertable probably depends on whether
0.0.5 supplies the appropriate conversion functions for earlier versions
of Cat. Possibly these can be assumed in some cases, such as when the
attribute list hasn't changed.
: 1) Cat-0.0.1 is used since it is in the local scope, so clearly the
: users choice.
:
: 2) Cat-0.0.5 is used since it is loaded after Cat-0.0.1.
:
: 3) An Ambiguity error is thrown because "Cat" is not specific enough.
4) The Cat alias is lexically scoped, and two different scopes can
have two diffferent aliases.
: Any option other than 1 requires the user to know what is going on
: within PetStore.
I think it just requires that later versions of Cat know how to deal
with earlier versions.
: >If you're using two different versions explicitly within the same
: >scope, you should
: >probably be required to alias one of them. The main purpose of
: >version
: >co-existence is for different modules to use different versions, not
: >the same module. I think using two different versions from the same
: >module is going to be relatively rare.
:
: Well, the first thing that comes to mind is that you could create a
: "best-of-both-worlds" proxy object/module. Say some insane CPAN
: developer radically changes an API, some of the changes make senses,
: some of the changes clearly illustrate the developers insanity. It
: might be useful to be able to create some kind of mix-up of the two
: module versions in which you alias part of each API (assuming they
: can co-exist peacefully that is).
:
: Sure it's an out-on-the-edge case, but I could see some possible
: usefulness.
Well, sure, I'm not trying to disallow it, just re-Huffmanize it.
The explicit aliasing mechanism (using :as<NewCat>, perhaps) should
be sufficient to handle the marginal cases without complicating
the implicit aliasing mechanism. The exporter is already in the
business of aliasing various names into the current namespace, so
making it alias the whole module is no big deal. No need for extra
built-in syntax.
Larry
Nate Wiger
> Nicholas,
>
> This is addressed in S11, here is a link:
>
> http://search.cpan.org/~ingy/Perl6-Bible/lib/Perl6/Bible/S11.pod
>
> To summarize, the syntax to load the modules is:
>
> use Dog-1.2.1;
>
> While the syntax to create a specific version of a module is:
>
> my Dog-1.3.4-cpan:JRANDOM $spot .= new("woof");
I'd really like to see a more extensible syntax for this. So:
use Dog 1.2.1; # ala Perl5
And then to extend:
use Dog { version => 1.2.1, cpanid => 'JRANDOM' };
This would allow arbitrary specifications, ie:
use Dog { interface => 0.2,
version => ['>=', 1.2.1],
company => 'Sun Microsystems'
};
> I addresses the class creation syntax partially in the initial version
> of the Metamodel prototype, which was built in p5. I basically just
> aliased the package with the long name (%{"Dog-1.3.4- cpan:JRANDOM::"} =
> %{"Dog::"}). However this does no good for loading of modules.
Building off the above:
%{Dog}{1.2.1}{JRANDOM}
Or some such, with the longest-matching object winning.
-Nate
Larry Wall
Well, we thought about opening it up like that, but we really kinda
need to establish what is an official part of the "long name" for
uniqueness purposes, and try to avoid too much visual clutter in
standard usage. That being said, you can certainly add additional
search constraints on a "use" by passing adverbs, but those aren't
counted as part of the official long name. And we do leave the
meaning of "naming authority" open, so that part is still subject
to extension, and that's one reason we put the naming authority at
the end. We could even add more hypthenated fields if they were
deemed to be of universal significance.
Larry
Nate Wiger
> Well, we thought about opening it up like that, but we really kinda
> need to establish what is an official part of the "long name" for
> uniqueness purposes, and try to avoid too much visual clutter in
> standard usage.
Going with that... I would think that the "official" part is really just
the module name. Are there lots of problems with CPAN collisions between
different authors? No. People just choose a slightly different name if
their preferred one is taken.
It seems the biggest problem is requiring *only* a specific version, or
range of versions, or <= a version. I know this is addressed already.
Not trying to rant (really), but one thing that is starting to bother me
about Perl 6 is that there's lots of changes that require special syntax
for one specific instance. It's making it really really difficult to
remember or generalize, two things that I thought we were trying to improve.
-Nate
Larry Wall
: Larry Wall wrote:
: >Well, we thought about opening it up like that, but we really kinda
: >need to establish what is an official part of the "long name" for
: >uniqueness purposes, and try to avoid too much visual clutter in
: >standard usage.
:
: Going with that... I would think that the "official" part is really just
: the module name. Are there lots of problems with CPAN collisions between
: different authors? No. People just choose a slightly different name if
: their preferred one is taken.
Now imagine that process applied to a CPAN that 20 years old and 200
times as big. We're trying to avoid the equivalent of DLL hell here,
and I think this is one are where .NET got it pretty much right.
: It seems the biggest problem is requiring *only* a specific version, or
: range of versions, or <= a version. I know this is addressed already.
We can squabble about the syntax, but the basic components of the long
name are all pretty important.
This is one of those accomodations to the real world, like everyone
agreeing on a standard URI format. We're really trying to keep
these module names close to what you'd see as the name of, say,
the corresponding .rpm file. These modules have to have names that
work outside of Perl as well as inside, and {...} isn't going to fly
in general.
: Not trying to rant (really), but one thing that is starting to bother me
: about Perl 6 is that there's lots of changes that require special syntax
: for one specific instance. It's making it really really difficult to
: remember or generalize, two things that I thought we were trying to improve.
Well, you're painting with kind of a broad brush here. If you can
point to other areas where we could usefully generalize without
getting too abstract for newbies, I'd be delighted to hear them.
Much better to spot our limitations now than later, even if we
decide we have to keep the limitations for some reason.
Larry
Nate Wiger
> This is one of those accomodations to the real world, like everyone
> agreeing on a standard URI format. We're really trying to keep
> these module names close to what you'd see as the name of, say,
> the corresponding .rpm file. These modules have to have names that
> work outside of Perl as well as inside, and {...} isn't going to fly
> in general.
My concern is that we're solving problems that don't really exist in
real-world Perl usage. Are there really two competing authors of DBI?
Or, for any product, do two people really try to market "SuperWidget"?
No, one person just changes to "SuperGadget". And with URI's, one person
gets "amazon.com". Sorry, name taken.
I think we're actually *encouraging* problems by allowing long, clashing
names. Pretty soon all DBI modules will have to start with
use DBI:TIMB;
Because "JEFFSTER" decided to upload his DBI (Derivative Binary Index)
module.
I think it will have the opposite effect of what we're trying to avoid.
> : Not trying to rant (really), but one thing that is starting to bother me
> : about Perl 6 is that there's lots of changes that require special syntax
> : for one specific instance. It's making it really really difficult to
> : remember or generalize, two things that I thought we were trying to improve.
>
> Well, you're painting with kind of a broad brush here. If you can
> point to other areas where we could usefully generalize without
> getting too abstract for newbies, I'd be delighted to hear them.
The method syntax is starting to make my head spin, for one.
Many things, as a longtime Perl 4/5 programmer and CPAN goon, are
problematic because we're reusing established operators for completely
different ideas. From a design standpoint, I feel it's going to hamper
adoption of the language. People don't have the time (or interest) to
re-learn that much language, when Perl 5 works fantastic for 95% of
the cases.
-Nate
Rob Kinyon
> My concern is that we're solving problems that don't really exist in
> real-world Perl usage. Are there really two competing authors of DBI?
> Or, for any product, do two people really try to market "SuperWidget"?
> No, one person just changes to "SuperGadget". And with URI's, one person
> gets "amazon.com". Sorry, name taken.
>
> I think we're actually *encouraging* problems by allowing long, clashing
> names. Pretty soon all DBI modules will have to start with
>
> use DBI:TIMB;
>
> Because "JEFFSTER" decided to upload his DBI (Derivative Binary Index)
> module.
>
> I think it will have the opposite effect of what we're trying to avoid.
I'm of two minds about this, in large part because I have two
experiences with the current CPAN.
My first CPAN module was taking over PDF::Template, originally written
by DFERRANCE. Now, it's maintained by RKINYON, soon to be maintained
by RKINYON and STEVAN due to amazing contributions by AUTRIJUS (or
whatever those characters are supposed to be).
Now, how are authorship-changes going to be handled, particularly in
the face of having two PDF::Templates out there already? Everyone is
disambiguating their modules with PDF::Template-DFERRANCE vs.
PDF::Template-JRANDOM. Now, they cannot upgrade to my latest feature
because that requires changing every place they had hard-coded
DFERRANCE. Or, will the package system map PDF::Template-DFERRANCE to
PDF::Template-RKINYON?
The second experience is one I'm going through right now. I was adding
a feature to Tree:Simple a few weeks back and realized that it needed
to be gutted to do what I needed it to do. With the encouragement of
the author, I rewrote it completely. My development name for the
distro is "Forest", but I have Tree and Tree::Binary as the packages.
(Yeah, it's a math joke.)
Except, there's two problems with that - Tree is a TLN (top-level
namespace) with a lot of unrelated distros beneath it. And, Tree is
owned by someone else, but that person hasn't updated Tree in 6 years.
And, Tree::Binary is owned by the same guy who owns Tree::Simple.
How is that going to work in P6? (For the record, I still haven't
figured out what I'm going to do yet. Check Perlmonks for the SOPW in
a few minutes.)
Rob
Larry Wall
I suspect you just use PDF::Template and have some other way of
instructing the library system about your general policy preferences,
so that anywhere that uses PDF::Template on your project uses the
same one by default.
: The second experience is one I'm going through right now. I was adding
: a feature to Tree:Simple a few weeks back and realized that it needed
: to be gutted to do what I needed it to do. With the encouragement of
: the author, I rewrote it completely. My development name for the
: distro is "Forest", but I have Tree and Tree::Binary as the packages.
: (Yeah, it's a math joke.)
:
: Except, there's two problems with that - Tree is a TLN (top-level
: namespace) with a lot of unrelated distros beneath it. And, Tree is
: owned by someone else, but that person hasn't updated Tree in 6 years.
: And, Tree::Binary is owned by the same guy who owns Tree::Simple.
:
: How is that going to work in P6? (For the record, I still haven't
: figured out what I'm going to do yet. Check Perlmonks for the SOPW in
: a few minutes.)
We probably need some meta-information somewhere about which names claim
to offer the same interface, and which are just accidental collisions.
That part isn't terribly well defined yet.
Larry
Larry Wall
: Larry Wall wrote:
: >This is one of those accomodations to the real world, like everyone
: >agreeing on a standard URI format. We're really trying to keep
: >these module names close to what you'd see as the name of, say,
: >the corresponding .rpm file. These modules have to have names that
: >work outside of Perl as well as inside, and {...} isn't going to fly
: >in general.
:
: My concern is that we're solving problems that don't really exist in
: real-world Perl usage. Are there really two competing authors of DBI?
: Or, for any product, do two people really try to market "SuperWidget"?
: No, one person just changes to "SuperGadget". And with URI's, one person
: gets "amazon.com". Sorry, name taken.
:
: I think we're actually *encouraging* problems by allowing long, clashing
: names. Pretty soon all DBI modules will have to start with
:
: use DBI:TIMB;
:
: Because "JEFFSTER" decided to upload his DBI (Derivative Binary Index)
: module.
:
: I think it will have the opposite effect of what we're trying to avoid.
I think there can be some kind of community metainformation that sets
defaults appropriately. And if not, the site/project can certainly
establish defaults. On the other hand, a lot of projects do simply
want to specify the version and author explicitly eveyr time,
and they'd rather tweak it by hand (or by script) if they want to
change it, since then at least they know when they need to rerun the
regression tests.
But we put the author last partly because we want to encourage people
not to use that if they don't need to. And the community may choose
to just stick with version numbers and names, and then "author" gets
retargeted as any kind of differentiator you need for occasional but
not regular use.
: >: Not trying to rant (really), but one thing that is starting to bother me
: >: about Perl 6 is that there's lots of changes that require special syntax
: >: for one specific instance. It's making it really really difficult to
: >: remember or generalize, two things that I thought we were trying to
: >improve.
: >
: >Well, you're painting with kind of a broad brush here. If you can
: >point to other areas where we could usefully generalize without
: >getting too abstract for newbies, I'd be delighted to hear them.
:
: The method syntax is starting to make my head spin, for one.
You mean the "pattern matching" characters on the dispatcher? Or the
method declaration syntax? Which part is making your head spin?
: Many things, as a longtime Perl 4/5 programmer and CPAN goon, are
: problematic because we're reusing established operators for completely
: different ideas. From a design standpoint, I feel it's going to hamper
: adoption of the language. People don't have the time (or interest) to
: re-learn that much language, when Perl 5 works fantastic for 95% of
: the cases.
But now you're changing your complaint. If we apply your previous
complaint to this, in many cases we're doing that redesign *precisely*
to fix the thing you're complaining about--too many special cases for
one instance...only it's Perl 5 that's the culprit here, not Perl 6.
In Perl 6 we've greatly regularized the special cases and reserved
most of the special syntax for common cases. Or more precisely, for
what we *suspect* will be common cases in the future, not necessarily
the common cases in the past.
Larry
Nate Wiger
> I think there can be some kind of community metainformation that sets
> defaults appropriately. And if not, the site/project can certainly
> establish defaults. On the other hand, a lot of projects do simply
> want to specify the version and author explicitly eveyr time,
> and they'd rather tweak it by hand (or by script) if they want to
> change it, since then at least they know when they need to rerun the
> regression tests.
I think it's a laudable idea in theory, but not necessarily application.
I've done quite alot of Perl programming, and I've never run into this
personally. Who has? (Really, I'm being serious.) Are there really
multiple modules sharing interchangeable interfaces? Or instances where
we want to allow the same name to mean different concepts depending on
the author?
There's no logical difference between:
use DBI:TIMB
use DBI:JEFFSTER
And:
use TIMB::DBI
use JEFFSTER::DBI
Anyways, I don't like the idea of people being able to upload
identically named modules to CPAN. I think that's a very bad idea. See
Rob Kinyon's message.
> You mean the "pattern matching" characters on the dispatcher? Or the
> method declaration syntax? Which part is making your head spin?
Yes. :-)
> But now you're changing your complaint. If we apply your previous
> complaint to this, in many cases we're doing that redesign *precisely*
> to fix the thing you're complaining about--too many special cases for
> one instance...only it's Perl 5 that's the culprit here, not Perl 6.
> In Perl 6 we've greatly regularized the special cases and reserved
> most of the special syntax for common cases. Or more precisely, for
> what we *suspect* will be common cases in the future, not necessarily
> the common cases in the past.
And I think that's actually my problem right now. Back when Perl 6
design started in 1999/2000 (and we wrote all the original RFC's), we
were careful not to throw the entire enchilada out. Perl 5 is enormously
successful because is solves *actual* problems, not *suspected* problems.
And, it shares alot with other languages people know and use.
Right now the design is going towards something that's very very
un-Perlish from a syntax standpoint. Sure, the philosophy's there, but
there are fewer and fewer things Perl 6 shares with Perl 5 (or other
widely-used languages).
And there are many superflous changes, such as using $0 as the first
match, where every other accepted regex engine/program on the planet uses 1.
Anyways, I'm not trying to rant or be obstructive (really); I am simply
trying to provide a slightly different perspective on a few things.
-Nate
Rob Kinyon
> Larry Wall wrote:
> > I think there can be some kind of community metainformation that sets
> > defaults appropriately. And if not, the site/project can certainly
> > establish defaults. On the other hand, a lot of projects do simply
> > want to specify the version and author explicitly eveyr time,
> > and they'd rather tweak it by hand (or by script) if they want to
> > change it, since then at least they know when they need to rerun the
> > regression tests.
>
> I think it's a laudable idea in theory, but not necessarily application.
> I've done quite alot of Perl programming, and I've never run into this
> personally. Who has? (Really, I'm being serious.) Are there really
> multiple modules sharing interchangeable interfaces? Or instances where
> we want to allow the same name to mean different concepts depending on
> the author?
Please see http://www.perlmonks.org/?node_id=501496 for more on the
issue of names. My Tree module and Schwern's Tree distro have almost
zero interface compatibility. They both represent N-ary trees, except
mine exposes the tree interface and Schwern's is just a OO interface
for a hash implemented as a tree. My module is descended from
Tree::Simple, except ::Simple almost never is.
The same thing goes for my version of Tree::Binary and Stevan
Little's. Two completely different interfaces, but here we're solving
the same problem. The major difference between mine and his is that
mine inherits from my Tree whereas his is an independent module. This
means that adding transparent persistence (which is what my rewrite
does) to his module is a bit of a bear.
Hence, you might want to use RKINYON's Tree::Binary over STEVAN's
Tree::Binary. Or, what should I call mine? (This is a real question -
if you have any suggestions, please let me know!)
> There's no logical difference between:
>
> use DBI:TIMB
> use DBI:JEFFSTER
>
> And:
>
> use TIMB::DBI
> use JEFFSTER::DBI
No, this isn't any good, either. I took over DFERRANCE's PDF::Template
implementation. He has nothing to do with it anymore. So,
DFERRANCE::PDF::Template now becomes RKINYON::PDF::Template? Or, does
RKINYON now maintain something in the DFERRANCE namespace? What on
earth does the name DFERRANCE provide, except for an additional layer
of confusion.
> Anyways, I don't like the idea of people being able to upload
> identically named modules to CPAN. I think that's a very bad idea. See
> Rob Kinyon's message.
I think you misinterpreted my message. My point is that uploading
things with the same name is a good plan, but it has to be thought
through, especially given the points I raised. But, I very much agree
that it should happen.
I'd like to propose a slight shift in emphasis. I think that more
focus needs to be made in project-wide or namespace-wide
disambiguation and module aliasing. If I was able to say in my CP6AN
distro that I depend on DBI:2.05-:cpan-TIMB and that I'm going to call
it DBI, then all the files in my distro should automatically have that
alias built in. This means that anyone wanting to use DBI:cpan-JRANDOM
in their code can alias it as DBI on a project-wide basis, yet still
be able to use my distro and everything be ok.
The important thing here, I think, is that while aliasing package
names is a lexical action, there can be a larger lexical scope. It may
be that we need the concept of a "Project", along with Module,
Package, Class, and Role. This way, the Project states "Whenever you
load a file that matches the criteria below, apply the following
lexical _stuff_."
Rob
Rob Kinyon
That's more because languages are incestuous (like Perl) instead of
languages independently arriving at the same conclusions. Yes, the
"while" loop is going to look the same everywhere. But, the fact that
everyone uses $1 to mean the first match has nothing to do with
whether or not that's a good idea. The first engine did so, which
means the next one probably will.
> Right now the design is going towards something that's very very
> un-Perlish from a syntax standpoint. Sure, the philosophy's there, but
> there are fewer and fewer things Perl 6 shares with Perl 5 (or other
> widely-used languages).
I wholeheartedly disagree. You can take any piece of P5 code and, with
very few modifications, have it run as native P6 code. You won't be
using a ton of the greatest features, but we have that in P5. I once
taught a programmer who'd been using Perl for over a year how to use
hashes. I have an article coming up in early November on perl.com
about how and why to use subroutines. Just because _you_ know about
the feature doesn't mean the hoi-polloi do. Heck, I've been
programming in Perl for almost 10 years and I have NEVER written a
line of XS. I wouldn't know where to start.
Frankly, most of the features in P6 look to be usable by 1% of the
Perl developers, and then only about 1% of the time. Most of my P6 is
going to be very vanilla. I'll take advantage of most of the new list
operators and thoroughly abuse the class/role system, but I'm not
going to be writing my own grammars or deal with $0/$1/etc. I don't
deal with them now - I prefer named captures.
The point is that if you want to truly clean off the cruft, you have
to approach with a completely open mind. That open mind is going to
piss off a lot of people and you will never do everything you were
hoping to do, but the end product will be better off for it. You'll
never reach the moon unless you shoot for the stars.
Rob
Steve Simmons
> . . . We could even add more hypthenated fields if they were
> deemed to be of universal significance.
That way lies madness, or at least the X font naming system,
an example that should be avoided.
--
Realize that life is a situation comedy that will never be canceled. A
laugh track has been provided, and the reason why we are put in the
material world is to get more material.
From "Swami Beyondananda's Guidelines for Enlightenment"
Nate Wiger
> On 10/20/05, Nate Wiger <na...@sun.com> wrote:
>
>>And, it shares alot with other languages people know and use.
>
> That's more because languages are incestuous (like Perl) instead of
> languages independently arriving at the same conclusions. Yes, the
> "while" loop is going to look the same everywhere. But, the fact that
> everyone uses $1 to mean the first match has nothing to do with
> whether or not that's a good idea. The first engine did so, which
> means the next one probably will.
Of course - but that doesn't mean it's a bad thing. It makes Perl more
accessible and learnable - and easier to switch between (it is not the
only language for many programmers).
$1 is a prime example. $0 means the program name (all scopes). $1 is the
first match. It's been that way for a very, very, very long time, and
it works just great. There is no *compelling* reason to change this,
other than to satisfy a few people that think it "should be different".
>>Right now the design is going towards something that's very very
>>un-Perlish from a syntax standpoint. Sure, the philosophy's there, but
>>there are fewer and fewer things Perl 6 shares with Perl 5 (or other
>>widely-used languages).
>
> I wholeheartedly disagree. You can take any piece of P5 code and, with
> very few modifications, have it run as native P6 code.
I think it depends on what type of code you have. Maybe for your code
this is true, but my view appears a bit different.
> Frankly, most of the features in P6 look to be usable by 1% of the
> Perl developers, and then only about 1% of the time. Most of my P6 is
> going to be very vanilla. I'll take advantage of most of the new list
> operators and thoroughly abuse the class/role system, but I'm not
> going to be writing my own grammars or deal with $0/$1/etc.
Unfortunately many people WILL have to deal with such changes, and
the question should be: Does a given change offer a clear improvement?
As you said, if we're helping %1 of people %1 of the time, are the
other 99% really going to change all their scripts? No chance.
Anyways, don't misread me as a complete naysayer. But I'm lazy and
impatient, and am concerned the transition to Perl 6 is not going to
suit me. :-)
-Nate
Nicholas Clark
> $1 is a prime example. $0 means the program name (all scopes). $1 is the
> first match. It's been that way for a very, very, very long time, and
> it works just great. There is no *compelling* reason to change this,
> other than to satisfy a few people that think it "should be different".
I cannot agree. The reason you give is not "compelling". Neither is the more
important reason, that it regularises the numbers when using an array lookup
to find matches, $1 being $/[1], IIRC.
But there are good reasons to change, and better reasons than you state.
Nicholas Clark
Rob Kinyon
> the question should be: Does a given change offer a clear improvement?
> As you said, if we're helping %1 of people %1 of the time, are the
> other 99% really going to change all their scripts? No chance.
You again misread what I said. "The other 99%" aren't even going to
notice the changes. Remember - 90% of all Perl code in the wild that
should use hashes doesn't. 90% of all Perl code that should use map
and grep doesn't. 90% of all Perl code that should use regexes
doesn't. The authors of those programs aren't even going to notice
that P6 changed. All they're going to see is that there's a few VERY
MINOR syntactical changes, they'll adjust, and they'll be happy.
Please remember the primary uses of Perl5 - systems administration,
package management, and CGI scripts. By far, those are the
overwhelming uses of Perl. In fact, I would argue that 99% of all Perl
code in the world falls under those three categories.
If you don't believe me, read "The Pragmatic Programmer". These are
excellent programmers and their view of Perl is for:
1) Writing tests (pp. 53, 197)
2) Project management and glue (pp. 100-101)
In fact, they specifically state in Tip 28 that every programmer
should learn a "Text Manipulation Language" (the authors prefer Ruby
and Perl) in order to do these things.
These are "The other 90%" you refer to. They're not going to care one
way or the other. And, if they do, /usr/local/bin/perl won't suddenly
disappear like Cindarella at the ball, you know.
Rob
Steve Simmons
> On Wed, Oct 19, 2005 at 03:58:17PM -0700, Nate Wiger wrote:
>: I think it will have the opposite effect of what we're trying to avoid.
> I think there can be some kind of community metainformation that sets
> defaults appropriately. And if not, the site/project can certainly
> establish defaults. On the other hand, a lot of projects do simply
> want to specify the version and author explicitly eveyr time,
> and they'd rather tweak it by hand (or by script) if they want to
> change it, since then at least they know when they need to rerun the
> regression tests.
> But we put the author last partly because we want to encourage people
> not to use that if they don't need to. And the community may choose
> to just stick with version numbers and names, and then "author" gets
> retargeted as any kind of differentiator you need for occasional but
> not regular use.
This issue is getting close to something that used to be near and dear
to my heart -- trying to deploy perl programs with version-specific
and/or author-specific module needs into unpredictable environments
*and determining what's going on*.
I used to work for Worldcom ("Oh, I'm sorry." "Yeah, me too.") and
was writing tools that had to work in the legacy environments of 4 or 5
different companies. Our tools of course had their own version
requirements, and it looked like the only reliable way to do things
was to ship the entire damned module set with the tool. Couple that
with the nightmare of five different sysadmin groups maintaining ten
or twelve different perl trees, users with customized envs that modified
@INC, yadda, yadda, yadda, and madness ensued. It became effectively
impossible to tell what version of any module was loaded by a given
tool without building in huge amounts of debugging information --
assuming, of course, that the various module authors and rewriters
were good about updating the module identifying variables.
It sucked to be me. :-)
You can tell by the past tense that this isn't my problem any more;
I work in a more sane environment these days. Nonetheless at some
point I thought about this stuff fairly deeply and even wrote up an
RFC or two. I've just completed a scan over Apocalypse 12, and
noted that several of my favorite issues aren't addressed. To wit:
I make use of a module foo where 1.X had the interfaces I need, 2.X
broke them, and 3.X et all put some of them back. I'd prefer to
have 1.X, don't ever want 2.X, and will take 3.X et al if I have
to and cut back some of my tools functionality. I don't see an obvious
use of smartmatch that does this; wedging my old proposed syntax into
that of Apocalypse12 would get something like:
use Dog-{1,>=3};
where >=3 meant version greater than or equal to 3. (Yes, I realize
that this particular syntax probalby won't fly with smartmatch. It's
just an illustration, not an actual proposal). And of course the
range syntax would work, eg,
use Dog-{1,>=3,2.99.4..2.99.6};
add the indicated range to the list of acceptable versions.
Similarly, we sometimes wanted author to take a higher precedence
than version, ie, always use *my* version if available. Since we only
have three parts to name/version/author tuple, I'd make allow the
author name to come before the version when that's more important,
eg,
use Dog-{SCS,JLARKE}-{1,>=3};
My versions get tried first, then JLARKEs, and both are only accepted
if v1.X or 3 and up.
Combining them would be allowed, eg,
use Dog-{SCS-*},{JLARKE-{1,>=3};
or maybe
use Dog-{SCS-*,JLARKE-{1,>=3}};
because all my dogs have collars, and some of JLARKEs.
Since all of this leads to potential nightmares when trying to intermix
with other folks' code, it'd be nice to have a way that I can have my
Dog and somebody else can use their Dog without a dogfight ensuing. So
use Dog-{SCS-*,JLARKE-{1,>=3}} as MyDog;
means that MyDog always refers to the matched version of Dog. If
someone else needs to
use Dog-*-JLARKE;
our Dogs each stay in their own yard and neither of us has to modify
code.
There's also the nightmare of how this is all stored in the filesystem.
We should bear in mind the legacy remark made of mh and netnews: a file
system is not a database, and attempts to do so cause severe performance
problems over time. But that's a different topic.
Nate Wiger
>
>>$1 is a prime example. $0 means the program name (all scopes). $1 is the
>>first match. It's been that way for a very, very, very long time, and
>>it works just great. There is no *compelling* reason to change this,
>>other than to satisfy a few people that think it "should be different".
>
> I cannot agree. The reason you give is not "compelling".
On the contrary, doing things "the established way" is perhaps THE most
compelling reason. After all, we're changing to "." for objects to be
like Java and other languages, right? EVERY other language (including
Perl 5) starts with $1 (or \1).
> Neither is the more
> important reason, that it regularises the numbers when using an
> array lookup to find matches, $1 being $/[1], IIRC.
If you could provide a real-world example where this helps, I'd
appreciate it. Again, I'm being sincere. I have never run into this
issue personally, so I'm trying to understand the benefit.
-Nate
Nate Wiger
> On 10/20/05, Nate Wiger <na...@sun.com> wrote:
>
>>$1 is a prime example. $0 means the program name (all scopes). $1 is the
>>first match. It's been that way for a very, very, very long time, and
>>it works just great. There is no *compelling* reason to change this,
>>other than to satisfy a few people that think it "should be different".
>
> portion of perl users, "Perl 5 works fantastic for 95% of the cases,"
> we have decided to develop a side project. You can join in by
> subscribing to perl5-...@perl.org.
Hah, that's clever.
I think you missed my point(s), but if you feel compelled to write me
off as a "complainer" just because I have a counter-opinion that is at
least somewhat built from a good amount of experience, then I do think
you're wearing a set of blinders to practical issues.
-Nate
Luke Palmer
> $1 is a prime example. $0 means the program name (all scopes). $1 is the
> first match. It's been that way for a very, very, very long time, and
> it works just great. There is no *compelling* reason to change this,
> other than to satisfy a few people that think it "should be different".
Thank you for your complaints. Now that we know that for a certain
portion of perl users, "Perl 5 works fantastic for 95% of the cases,"
we have decided to develop a side project. You can join in by
subscribing to perl5-...@perl.org.
Luke
Luke Palmer
Okay, I may still be missing your point, so let me try to summarize
just to be sure we're on the same page: You say that the thing that
is going to hinder migration to Perl 6 is the fact that it's different
from Perl 5.
We've known for quite a while that Perl 6 is not merely an "upgrade"
to Perl 5. We're designing a different language, but that language is
still Perl. Perl 5 is like seventeenth century English, Perl 6 is
like twenty-first century English (even though we don't quite know
what that is yet). The language changes with the people and the
times, and this sometimes means that the results will not be mutually
intelligible.
Our target audience is only somewhat from a Perl 5 background. People
from Java, from Python, from C, and even just starting to program will
be learning Perl 6, and they would rather have all the language be
zero-based, rather than most of it being zero-based except for $1, $2,
etc. (you were complaining about special exceptions if I recall).
The reason I'm dismissing you as a "complainer" is because of your
broad field of attack. You say that "the method syntax is starting to
make [your] head spin". Well, what about it is making your head spin?
The fact that we use . instead of -> (like every other language on
the planet)? The fact that there are two ways to call a method in
Perl 6:
$obj.meth($arg)
meth $obj: $arg
Rather than only two ways from Perl 5:
$obj->meth($arg)
meth $obj $arg
? The fact that we're declaring methods with "method" instead of "sub"?
If you want something to change, you should suggest a change. If you
think that Perl 6 is changing too much in general, and that we should
go back and make it more like Perl 5, you probably won't get your
wish. To a lot of us p6lers, we've been around Perl 6 for a long
time, and are starting to speak it natively. It feels right. And we
think that when somebody does invest the time to learn it[1], it will
start to feel right to them, too. And after those people have been
writing in Perl 6 for a year, they will be glad that we optimized for
the the Perl 6 programmer, rather than the learning Perl 5 programmer.
Luke
[1] Which will be, what, eight hours for a Perl 5 programmer? Have
you ever spent a month trying to learn, oh, say, Haskell? Because
people do that, too.
Nate Wiger
>
> Okay, I may still be missing your point, so let me try to summarize
> just to be sure we're on the same page: You say that the thing that
> is going to hinder migration to Perl 6 is the fact that it's different
> from Perl 5.
Intentionally trite oversimplification. My problem is that it's
different in some ways which are not truly useful, and that cause
unnecessary relearning/rewriting/incompatibilities.
> Our target audience is only somewhat from a Perl 5 background. People
> from Java, from Python, from C, and even just starting to program will
> be learning Perl 6, and they would rather have all the language be
> zero-based, rather than most of it being zero-based except for $1, $2,
> etc. (you were complaining about special exceptions if I recall).
Every regex engine in every language uses $1 or \1. This includes Java,
JavaScript, C, PHP, Python, awk, sed, the GNU regex libs, etc. Somehow
other languages seem ok with this, because it's a widely-used convention.
And you don't have to answer, but have you actually programmed in Java
or Python? You seem to be speaking for alot of programmers.
> The reason I'm dismissing you as a "complainer" is because of your
> broad field of attack. You say that "the method syntax is starting to
> make [your] head spin". Well, what about it is making your head spin?
The method: infix:<+> stuff makes no sense to me, but I don't want to
dwell on it.
> The fact that we use . instead of -> (like every other language on
> the planet)?
You're using my argument for me - thanks. See above.
> If you want something to change, you should suggest a change. If you
> think that Perl 6 is changing too much in general, and that we should
> go back and make it more like Perl 5, you probably won't get your
> wish.
That's not my wish; just that it's time to take "another look" at the
list of changes to see where the real-world benefit is.
> [1] Which will be, what, eight hours for a Perl 5 programmer? Have
> you ever spent a month trying to learn, oh, say, Haskell? Because
> people do that, too.
There are more components to this that just the learning time for one
person. There are project teams, sustaining engineering for existing
projects, etc. And that's not even counting management tape. Real-world,
profitable computing is a big, ugly, nasty beast.
If Perl 6 is going to be successful, this means it must change the
fewest key things with the most benefits. This may mean some things that
"aren't quite perfect" still don't get changed. (It also means lots of
new stuff can still be added - I'm just talking change.)
For example, NIS+ was released as a follow-up to NIS. It was supposed to
solve all the issues (mostly security) from NIS. But it was made too
complicated, and incompatible with NIS. People were supposed to re-learn
NIS and convert all their maps to NIS+. They didn't.
Just food for thought... maybe I'm wrong...
-Nate
Luke Palmer
> >
> > Okay, I may still be missing your point, so let me try to summarize
> > just to be sure we're on the same page: You say that the thing that
> > is going to hinder migration to Perl 6 is the fact that it's different
> > from Perl 5.
>
> Intentionally trite oversimplification.
Oh, sorry. I was going to expand on that, but then the direction of
my message changed and I forgot to. Sorry for my overall hostile
tone. I'll try to conduct myself civilly for the rest of the
argument.
> > Our target audience is only somewhat from a Perl 5 background. People
> > from Java, from Python, from C, and even just starting to program will
> > be learning Perl 6, and they would rather have all the language be
> > zero-based, rather than most of it being zero-based except for $1, $2,
> > etc. (you were complaining about special exceptions if I recall).
>
> Every regex engine in every language uses $1 or \1. This includes Java,
> JavaScript, C, PHP, Python, awk, sed, the GNU regex libs, etc. Somehow
> other languages seem ok with this, because it's a widely-used convention.
Yeah, well, every other regex engine on the planet uses [] for
character classes, no other regex engine uses <> for subrules, no
other regex engine uses a match object or nested capture numbering.
Perl 6's patterns are _not_ regexes anymore. But I doubt that we
won't be imitated, because the new regexes are way better than the old
ones. Breaking cruft for a reason and all that.
> And you don't have to answer, but have you actually programmed in Java
> or Python? You seem to be speaking for alot of programmers.
Yes, yes.
You seem to be speaking for a lot of programmers, too. We have to,
for if we didn't try, we probably wouldn't be good language designers.
> > The reason I'm dismissing you as a "complainer" is because of your
> > broad field of attack. You say that "the method syntax is starting to
> > make [your] head spin". Well, what about it is making your head spin?
>
> The method: infix:<+> stuff makes no sense to me, but I don't want to
> dwell on it.
Ahh, grammatical categories. You may already know this, but let me
try to explain. The category:<symbol> stuff is our way of letting the
user hook into the parser in common ways without them having to go and
explicitly change the grammar of the language. Generally, that syntax
has nothing to do with it being a method. Whatever you see inside the
quoter after the category is always introducing (or defining an
additional meaning for) a token, which I guess is why it's quoted.
> > The fact that we use . instead of -> (like every other language on
> > the planet)?
>
> You're using my argument for me - thanks. See above.
Huh? So you want to go back to Perl 5's arrow? *Anybody* coming to
Perl 6 from some non-Perl 5 language is going to be more comfortable
with dot.
> > [1] Which will be, what, eight hours for a Perl 5 programmer? Have
> > you ever spent a month trying to learn, oh, say, Haskell? Because
> > people do that, too.
>
> There are more components to this that just the learning time for one
> person. There are project teams, sustaining engineering for existing
> projects, etc. And that's not even counting management tape. Real-world,
> profitable computing is a big, ugly, nasty beast.
Which is why we're going to great lengths to make sure that your Perl
5 code and your Perl 6 code can run together.
use perl5:DBI;
The transition to Perl 6 doesn't mean that /usr/bin/perl is going to
change to version six under your feet and all your code will break.
> If Perl 6 is going to be successful, this means it must change the
> fewest key things with the most benefits. This may mean some things that
> "aren't quite perfect" still don't get changed. (It also means lots of
> new stuff can still be added - I'm just talking change.)
It sounds like you want a backwards-compatible change. From the
outset we knew that this wasn't our goal. Perl 5 is full to the brim
with syntax, and there's pretty much nowhere we can add anything, and
there's tons of cruft that we had to get rid of.
Consider Perl 6 to be a derivative, not an extension, of Perl 5.
Luke
Luke Palmer
> Then the target audience is specifically not people coming from a
> shell scripting background, who are quite used to the idea that $0 is
> different from $1 in a way in which $1 is not different from $2.
> Correct?
But $1 in Perl 5 wasn't the same as $1 in a shell script. The shell
scripters seemed to be able to substitute $ARGV[0] for $1 pretty well
nonetheless.
Luke
John Adams
From: Luke Palmer <lrpa...@gmail.com>
> Our target audience is only somewhat from a Perl 5 background. People
from Java, from Python, from C, and even just starting to program will
be learning Perl 6, and they would rather have all the language be
zero-based, rather than most of it being zero-based except for $1, $2,
etc.
Then the target audience is specifically not people coming from a shell scripting background, who are quite used to the idea that $0 is different from $1 in a way in which $1 is not different from $2. Correct?
John Adams
> But $1 in Perl 5 wasn't the same as $1 in a shell script.
Sure--but that's not what I said.
I'm all for breaking things that need breaking, which is why I keep my mouth shut most of the time--either I see the reason or I suspect (that is, take on faith, which is okay by me) there's a reason I don't see or fully understand. I'm just not seeing a compelling reason for this one, and a pretty good reason not to do it: I'm not aware offhand of any other place where $0 is used in regex matching, and several of the languages which you point out are zero-based in other places are not zero-based in regex matching.
Jonathan Scott Duff
> Every regex engine in every language uses $1 or \1. This includes Java,
> JavaScript, C, PHP, Python, awk, sed, the GNU regex libs, etc. Somehow
> other languages seem ok with this, because it's a widely-used convention.
This quibbling over $0 and $1 seems like rampant bikeshedding to me.
Given that @Larry has said that $0, $1, etc. correspond to $/[0], $/[1],
etc, if you want to keep $1 as the "first parenthesized part", then come
up with a compelling, concrete proposal for what to do with $/[0] (and
$0) keeping in mind that
@array = /(foo)(bar)(baz)/;
has to do the right thing.
> That's not my wish; just that it's time to take "another look" at the
> list of changes to see where the real-world benefit is.
IMHO, self consistency is far and away more important than consistency
with perl5.
> If Perl 6 is going to be successful, this means it must change the
> fewest key things with the most benefits. This may mean some things that
> "aren't quite perfect" still don't get changed. (It also means lots of
> new stuff can still be added - I'm just talking change.)
I don't understand this. Change the fewest "key things" relative to
what? Perl5? If so, why? Is it not enough that perl5 programs will
still compile and run under perl6?
> Just food for thought... maybe I'm wrong...
I don't know about wrong, but you're certainly entering the game a
little late.
-Scott
--
Jonathan Scott Duff
du...@pobox.com
Benjamin Smith
> On 10/20/05, Nate Wiger <na...@sun.com> wrote:
> > Luke Palmer wrote:
> > > The fact that we use . instead of -> (like every other language on
> > > the planet)?
> >
> > You're using my argument for me - thanks. See above.
>
> Huh? So you want to go back to Perl 5's arrow? *Anybody* coming to
> Perl 6 from some non-Perl 5 language is going to be more comfortable
> with dot.
Unless it was Smalltalk, C++, Haskell etc.
I really wish people wouldn't use the argument that . is used for method
calls everywhere. It's not.
Surely we have a much better argument in what we used -> for instead?
> > > [1] Which will be, what, eight hours for a Perl 5 programmer? Have
> > > you ever spent a month trying to learn, oh, say, Haskell? Because
> > > people do that, too.
> >
> > There are more components to this that just the learning time for one
> > person. There are project teams, sustaining engineering for existing
> > projects, etc. And that's not even counting management tape. Real-world,
> > profitable computing is a big, ugly, nasty beast.
Basically that would mean that any team would never be able to change
language, right? So there would be no difference if we wanted them to
change to Perl 5, Perl 6 or Haskell, so it doesn't seem very useful to
argue about this.
--
Benjamin Smith <bsm...@vtrl.co.uk, benjami...@yahoo.co.uk>
Luke Palmer
> On Thu, Oct 20, 2005 at 06:39:34PM -0600, Luke Palmer wrote:
> > Huh? So you want to go back to Perl 5's arrow? *Anybody* coming to
> > Perl 6 from some non-Perl 5 language is going to be more comfortable
> > with dot.
>
> Unless it was Smalltalk, C++, Haskell etc.
>
> I really wish people wouldn't use the argument that . is used for method
> calls everywhere. It's not.
Well, you know, for this kind of argument I would generally agree with
you. But I think in this case, I won't. The reasoning is a little
shakey, but I think it still works.
Smalltalk uses whitespace, therefore making it *the* fundamental
syntactic operation (like function application in Haskell). Since our
fundamental operation is not method call, it doesn't count.
C++ uses dot half the time.
Haskell doesn't really have methods. They're just functions. We
aren't taking that conceptual route, so Haskell doesn't count either.
Dot is probably the most semantically consistent character of modern
programming languages, second only to perhaps parentheses.
Luke
Luke Palmer
> On 10/21/05, Benjamin Smith <bsm...@vtrl.co.uk> wrote:
> > On Thu, Oct 20, 2005 at 06:39:34PM -0600, Luke Palmer wrote:
> > > Huh? So you want to go back to Perl 5's arrow? *Anybody* coming to
> > > Perl 6 from some non-Perl 5 language is going to be more comfortable
> > > with dot.
> >
> > Unless it was Smalltalk, C++, Haskell etc.
> >
> > I really wish people wouldn't use the argument that . is used for method
> > calls everywhere. It's not.
I guess I was saying that of the infix characters we had available to
choose, dot is the only one anybody uses. All the others are dotless,
so our attempts would be pointless, period.
Luke
Michele Dondi
> Huh? So you want to go back to Perl 5's arrow? *Anybody* coming to
> Perl 6 from some non-Perl 5 language is going to be more comfortable
> with dot.
(Also, I did like the arrow notation, but) how cool would be
@cool=grep ->cool, @misc; # if compared to
@cool=grep .cool, @misc; # ?
Michele
--
Jack Burton: This is Jack Burton in the Pork Chop Express, and I'm talkin'
to whoever's out there.
- Big Trouble in Little China (1986)
John Adams
From: "Patrick R. Michaud" <pmic...@pobox.com>
>I can state the compelling reason for this one -- it's way too
confusing when $1, $2, $3, etc. correspond to $/[0], $/[1], $/[2], etc.
>In many discussions of capturing semantics earlier in the year,
nearly everyone using $1, $2, $3 in examples, documentation, and
discussion was having trouble with off-by-one errors. This includes
the language designers, and even those who were advocating staying
with $1, $2, $3. Once we switched to using $0, $1, $2, etc.,
nearly all of the confusion and mistakes disappeared.
Okay, this I buy. There's a cost to it, but it's worth it.
Patrick R. Michaud
> From: Luke Palmer <lrpa...@gmail.com>
>
> > But $1 in Perl 5 wasn't the same as $1 in a shell script.
>
> keep my mouth shut most of the time--either I see the reason or
> I suspect (that is, take on faith, which is okay by me) there's
> a reason I don't see or fully understand. I'm just not seeing a
> compelling reason for this one, and a pretty good reason not to do it:
I can state the compelling reason for this one -- it's way too
confusing when $1, $2, $3, etc. correspond to $/[0], $/[1], $/[2], etc.
In many discussions of capturing semantics earlier in the year,
nearly everyone using $1, $2, $3 in examples, documentation, and
discussion was having trouble with off-by-one errors. This includes
the language designers, and even those who were advocating staying
with $1, $2, $3. Once we switched to using $0, $1, $2, etc.,
nearly all of the confusion and mistakes disappeared.
> I'm not aware offhand of any other place where $0 is used in
> regex matching, and several of the languages which you point out
> are zero-based in other places are not zero-based in regex matching.
Yes, but none of those other regex matching languages do nested
captures either. In particular, a rule like:
/:w ( (\w+) = (\d+) ; )+ /
no longer captures to $1, $2, $3, or even to $0, $1, $2. It now
creates an array in $/[0] (aka $0), and each element of that array
contains a [0] and [1] index representing the second and third set of
parentheses in the rule. That is
"a=4; b=2; c=8;" ~~ /:w ( (\w+) = (\d+) ; )+ /
results in
$/[0][0][0] == 'a' $/[0][0][1] == '4'
$/[0][1][0] == 'b' $/[0][1][1] == '2'
$/[0][2][0] == 'c' $/[0][2][1] == '8'
Trying to make *all* of these indexes 1-based leads to
chaos (especially wrt array assignment), and saying that top
level parens in a rule are named $1, $2, $3, ... while nested parens
are named [0], [1], [2], ... just throws everything and
everyone off. It's *much* easier when everything is zero-based,
even for those who are used to using $1, $2, $3 in regular
expressions.
Pm
Nate Wiger
>>Every regex engine in every language uses $1 or \1. This includes Java,
>>JavaScript, C, PHP, Python, awk, sed, the GNU regex libs, etc. Somehow
>>other languages seem ok with this, because it's a widely-used convention.
>
> won't be imitated, because the new regexes are way better than the old
> ones. Breaking cruft for a reason and all that.
Ok, I'll wait on this one. I've said my piece. Maybe they'll go back and
update awk and sed after Perl 6 comes out. (Ok now I'm just being
sarcastic, sorry. :-)
>>>The fact that we use . instead of -> (like every other language on
>>>the planet)?
>>
>>You're using my argument for me - thanks. See above.
>
> Huh? So you want to go back to Perl 5's arrow? *Anybody* coming to
> Perl 6 from some non-Perl 5 language is going to be more comfortable
> with dot.
No, no, you misread that completely. Basically, you're saying to use the
"." for objects because "everyone else does". I'm using the same
supporting argument ("everyone else does") for why to start with $1.
BTW, C and PHP both use -> "still".
> It sounds like you want a backwards-compatible change. From the
> outset we knew that this wasn't our goal. Perl 5 is full to the brim
> with syntax, and there's pretty much nowhere we can add anything, and
> there's tons of cruft that we had to get rid of.
>
> Consider Perl 6 to be a derivative, not an extension, of Perl 5.
I really do understand that - really. But I think things are getting a
bit overboard. The Latin-1 sigil is another discussion that nobody wants
to admit is a legit problem, despite numerous legitimate issues. Even
being able to type in the syntax itself is going to be problematic!
Anyways, you can listen or not listen to those of us from real, large,
corporate environments. I'm just trying to temper the enthusiasm for
many of the real improvements in Perl 6 with some of the real costs -
which are largely being ignored as "no big deal".
I'm a big Perl advocate, but I guess I'm just not sure if I'm gonna be a
big Perl 6 advocate yet. There's alot of downsides and real business risk.
-Nate
Mark Reed
> BTW, C and PHP both use -> "still".
C++ is probably more relevant than C, but since it inherited the syntax,
same diff. But in their case the underlying form is still a dot; A->B is
just syntactic sugar for (*A).B. The distinction involved doesn't really
exist in Perl, so it only needed one form, and $Larry decided to go with dot
for concatenation and the arrow for dereferencing. Then enough other
languages made the opposite choice that a rethink was warranted.
PHP was just copying Perl5, so it doesn't count. :)
> I really do understand that - really. But I think things are getting a
> bit overboard. The Latin-1 sigil is another discussion that nobody wants
> to admit is a legit problem, despite numerous legitimate issues. Even
> being able to type in the syntax itself is going to be problematic!
It's more a case of having had the discussion over and over again already, I
think. Nothing came up in this thread that hadn't been said before. The
design team is aware of the issues - really. They simply have decided that
the trade-off in legibility worth it.
> Anyways, you can listen or not listen to those of us from real, large,
> corporate environments. I'm just trying to temper the enthusiasm for
> many of the real improvements in Perl 6 with some of the real costs -
> which are largely being ignored as "no big deal".
Again, I don't think it's "no big deal" so much as "already acknowledged and
stipulated." For instance, we already have non-ASCII operators, so the
introduction of ¢ doesn't introduce any new issues of the sort being
discussed.
> I'm a big Perl advocate, but I guess I'm just not sure if I'm gonna be a
> big Perl 6 advocate yet. There's alot of downsides and real business risk.
I don't think there are "a lot of downsides". There is definitely a risk,
as with any new technology, and I'm largely adopting a wait-and-see attitude
myself, but I don't see any huge negatives anywhere. What are these
downsides?
From a practical standpoint, it will be a while before I have to worry about
Perl6 professionally, because we're not going to want to use it until it's
been around long enough to have some kinks worked out.
Rob Kinyon
for "Reply to All".
Rob
---------- Forwarded message ----------
From: Nate Wiger <na...@sun.com>
Date: Oct 21, 2005 2:38 PM
Subject: Re: $1 change issues [was Re: syntax for accessing multiple
versions of a module]
To: Rob Kinyon <rob.k...@gmail.com>
Rob-
>>BTW, C and PHP both use -> "still".
>
> That's because PHP is a Perl templating engine that got too big for
> its britches. (http://www.devshed.com/c/a/PHP/An-Introduction-to-PHP/)
Hah, that's a funny way to look at it. Although, PHP forked back in
1997, reading the article. There's alot of stuff it does differently
nowadays, some better, some worse.
>>Anyways, you can listen or not listen to those of us from real, large,
>>corporate environments. I'm just trying to temper the enthusiasm for
>>many of the real improvements in Perl 6 with some of the real costs -
>>which are largely being ignored as "no big deal".
>
> I think YOU forget that nearly everyone else on this list, including
> @Larry, has worked in large corporate environments. My understanding
> of the response has been "Yes, there might be issues. They are all
> solveable with a little elbow grease." And, frankly, you can run every
> P5 program under Perl6. I'm not seeing what the problem is.
Fair enough. Maybe I'm just a whiner. That's possible.
But, I'm on the cusp of a major new outing, namely [snip]. The
point is, I don't like the idea of having to relearn a ton of stuff
midway thru the 5+ year product cycle of [snip]. So I'll probably end up
choosing a different language for the team to use, which is too bad.
-Nate
P.S. I didn't post this to the list, because you didn't
Chromatic
> If Perl 6 is going to be successful, this means it must change the
> fewest key things with the most benefits.
I think there's an assumption here that not only do I not hold but I do
not even understand.
Suppose that I am a game developer with a small, very devoted and vocal
group of fans. I interact with them regularly through IRC, message
boards, and occasionally even private e-mail.
I decide to create a new game and start to do some market research.
Obviously I ask my core group of fans what they want. They oblige: more
of everything they loved from previous games, harder difficulties, more
in-jokes, and all of the new features they've always wanted in my
previous games.
I listen to them and write the game that my core fans want and, if I'm
really surprisingly amazingly lucky, other people want it too and it's a
success.
More likely, it sells a few copies outside of my fanbase and I learn a
painful lesson: there are more people you are not currently reaching
than you are currently reaching.
It's worth keeping them in mind.
-- c
Michele Dondi
>> just to be sure we're on the same page: You say that the thing that
>> is going to hinder migration to Perl 6 is the fact that it's different
>> from Perl 5.
>
> Intentionally trite oversimplification. My problem is that it's
> different in some ways which are not truly useful, and that cause
> unnecessary relearning/rewriting/incompatibilities.
I've waited long before answering this mail because I wanted to see more
along the way of the Perl6 fears "thread".
Now the observation above gives me a chance to express my own
perlplexities. I'm not bothered by the changes in themselves nor am I
concerned by the necessary (or not)
relearning/rewriting/incompatibilities.
<thepoint>
But there's an observation I can't help doing: it seems to me that the
ratio of increase in the complexity of (some aspects of) the language _is_
_much_ _bigger_ than that in the functionality such complexity is supposed
to provide.
</thepoint>
Let me explain: we all know that Perl5 has a very simple parameter passing
mechanism for subs and an even more rudimentary {prototyping,signature}
mechanism that one actually seldom uses. With this simple mechanism one
can implement or fake quite a lot of parameter passing paradigms.
It seems to me that this covers at least 90% of one's common needs. But
for simple subs in Perl6 I will probably still use @_; err... that or the
new pointy subs which are indeed so cool! Whatever, the new system by
contrast seems to me to be at least 400% more complex, but it won't buy me
400% more functionality.
Quite similarly the old OO support was so light to the point of being
immaterial, so that many people even thin it plainly sucks. But in
retrospect it was amazing to note how many OO paradigms and techniques one
coudl get out of simple, tiny, appearently innocent function called
bless()! Of course these implied lots of workarounds and hacks, be them
damn sexy hacks, but hacks: ok, granted! But the new system is what? 10k%
more complex? The question is: does this buy me all that 10k% more
functionality, or would have been a _simpler_ design, say "only" 1k% more
complex be enough?
It is always amazing, both in a programming language (or CS) context and
in totally unrelated ones, when from a simple scheme you can draw a rich,
huge set of consequences. But of course is not in Perl's nature an aim for
extreme simplicity; nothing to say... Perl5 is full of inconsistencies
in the form ad hoc dwimmeries and magic, while Perl6 already cures them by
trying to make them into "structural" magic of a globally more coherent
and consistent framework. But it's still my impression that it's pushing
in quite _too_ much structural complexity as well.
This is fundamentally the _only_ perlplexity about Perl6 I have...
Of course this is only a meditation and I know that I'm not knowledgeable
enough to be fully aware of all the implications of some aspects I've
touched upon in this writing, and thus I'm not expecting it to change or
influence the direction of evolution of language (re-)design. Just wanted
to let you all know.
Michele
--
Ira Kane: You wouldn't understand.
Dr. Allison Reed: No, how could I? I'm just a humorless ice queen in
desperate need of a good humping.
Ira Kane: Oh... you heard that, huh?
Dr. Allison Reed: Loud and clear.
- "Evolution", Ivan Reitman
Juerd
> Let me explain: we all know that Perl5 has a very simple parameter
> passing mechanism for subs and an even more rudimentary
> {prototyping,signature} mechanism that one actually seldom uses.
It is unused because it sucks. </blunt>
> With this simple mechanism one can implement or fake quite a lot of
> parameter passing paradigms.
And it is a lot of work to do so.
> for simple subs in Perl6 I will probably still use @_
You'd be a fool to do so, with the sole exception of list manipulation,
which at least in my codebase isn't used quite that much, and almost
never listens to the qualification "simple sub".
Compare:
sub dosomething { @_[0] blah @_[1] }
sub dosomething ($a, $b) { $a blah $b }
sub dosomething { $^a blah $^b }
The @_ solution is really the most ugly and hard to type of the three
possibilities.
> err... that or the new pointy subs which are indeed so cool!
Cool, but probably not a good idea for named subs, if only for style.
our &dosomething ::= -> $a, $b { $a blah $b }
Not really a winner in any perspective.
> Whatever, the new system by contrast seems to me to be at least 400%
> more complex, but it won't buy me 400% more functionality.
It will buy you 400% in saving typing, 4000% in less debubbing and
40000% in maintainability(==readability).
> But the new system is what? 10k% more complex? The question is: does
> this buy me all that 10k% more functionality, or would have been a
> _simpler_ design, say "only" 1k% more complex be enough?
I love the OO system, and although it adds to complexity, I believe the
functionality gained is much greater. However, I do not see why we need
to add three ugly operators for features that I suspect almost nobody
will use: .?, .* and .+
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Michele Dondi
>> for simple subs in Perl6 I will probably still use @_
>
> You'd be a fool to do so, with the sole exception of list manipulation,
[snip]
> Compare:
>
> sub dosomething { @_[0] blah @_[1] }
>
> sub dosomething ($a, $b) { $a blah $b }
>
> sub dosomething { $^a blah $^b }
Ouch! I take back my words... (should've thought of it better!)
> The @_ solution is really the most ugly and hard to type of the three
> possibilities.
I currently only rarely use @_ *directly*. I C<shift> and assign a lot
instead. Indeed both are still unnecessarily complex and I once gain take
back my word.
I'm still convinced my remark _partly_ applies in the sense that the
overall impression is that a vast majority of most common needs is
addressed by a *subset* of the current features and trying to stuff all
them in has brought in quite a lot of discussions of which I'm not even
sure if they've all settled down.
Michele
--
> [are there] Any areas of mathematical knowledge or skills that we lost?
Yes, but I don't remember what they are.
- Kevin Foltinek in sci.math [edited]
Rob Kinyon
> I'm still convinced my remark _partly_ applies in the sense that the
> overall impression is that a vast majority of most common needs is
> addressed by a *subset* of the current features and trying to stuff all
> them in has brought in quite a lot of discussions of which I'm not even
> sure if they've all settled down.
I think a good comparison can be made to Ruby. For work, I've been
learning Ruby this past week (we're going to try out Rails to see if
we like it). As my colleague put it, Ruby has all the P6 features we
want and it's usable now.
Ruby's OO system is 1000% more complex that Perl5's. Yet, it's still a
net win. For one thing, I don't have to write the following anymore
(lifted from a CPAN module I am working on):
sub children {
my $self = shift;
if ( caller->isa( __PACKAGE__ ) || $self->isa( scalar(caller) ) ) {
return wantarray ? @{$self->{_children}} : $self->{_children};
}
else {
return @{$self->{_children}};
}
}
This is in a vain attempt to implement a protected subroutine. In
fact, I really want a private writing accessor with a public reading
accessor, but have absolutely no way to implement that.
Why do I want such a beast? Because I want to GUARANTEE in an absolute
kind of way that, unless my user truly intended to do so, he's not
going to be able to accidentally screw up my internal state.
And, no, I don't want to use inside-out classes. They're "cool" (in
all the good and bad senses of the word), don't play well with other
P5 solutions, and STILL don't provide the necessary granularity. The
problem isn't with $object->{foo} = 3; The problem is with the
subroutines that aren't real methods with correct protection
mechanisms.
So, for a bit of extra complexity, I get peace of mind for myself and my users.
(Oh, and Ruby has first-class block. W00T!)
Rob
Sebastian
> 40000% in maintainability(==readability).
I think this is the main point here. With @_ and bless() you could do
cool things, but again it happened at the expense of repetition and
all those other buzzwords (maintainability, et al). As long as p6
isn't taking away from any of the functionality or DWIMery I won't
have any objections
- Sebastian
Ilmari Vacklin
> sub dosomething { $^a blah $^b }
I think the $^ variables are only allowed in bare (or ->) blocks. (As a
guard against san.. er, madness.)
--
Ilmari Vacklin (wolverian)
Piers Cawley
> Michele Dondi skribis 2005-11-04 14:58 (+0100):
>> Let me explain: we all know that Perl5 has a very simple parameter
>> passing mechanism for subs and an even more rudimentary
>> {prototyping,signature} mechanism that one actually seldom uses.
>
> It is unused because it sucks. </blunt>
>
>> With this simple mechanism one can implement or fake quite a lot of
>> parameter passing paradigms.
>
> And it is a lot of work to do so.
>
>> for simple subs in Perl6 I will probably still use @_
>
> You'd be a fool to do so, with the sole exception of list manipulation,
> which at least in my codebase isn't used quite that much, and almost
> never listens to the qualification "simple sub".
>
> Compare:
>
> sub dosomething { @_[0] blah @_[1] }
>
> sub dosomething ($a, $b) { $a blah $b }
>
> sub dosomething { $^a blah $^b }
>
> The @_ solution is really the most ugly and hard to type of the three
> possibilities.
>
>> err... that or the new pointy subs which are indeed so cool!
>
> Cool, but probably not a good idea for named subs, if only for style.
>
> our &dosomething ::= -> $a, $b { $a blah $b }
>
> Not really a winner in any perspective.
And the return semantics of pointy blocks are different, you have to be careful
about doing an explicit return in them because that returns to the caller of
the lexical scope in which they were defined (otherwise for ... -> ... {...}
wouldn't work)
--
Piers Cawley <pdca...@bofh.org.uk>
http://www.bofh.org.uk/
Piers Cawley
> On 11/4/05, Michele Dondi <bla...@pcteor1.mi.infn.it> wrote:
>> I'm still convinced my remark _partly_ applies in the sense that the
>> overall impression is that a vast majority of most common needs is
>> addressed by a *subset* of the current features and trying to stuff all
>> them in has brought in quite a lot of discussions of which I'm not even
>> sure if they've all settled down.
>
> I think a good comparison can be made to Ruby. For work, I've been
> learning Ruby this past week (we're going to try out Rails to see if
> we like it). As my colleague put it, Ruby has all the P6 features we
> want and it's usable now.
>
> Ruby's OO system is 1000% more complex that Perl5's. Yet, it's still a
> net win. For one thing, I don't have to write the following anymore
> (lifted from a CPAN module I am working on):
The thing about Ruby (and Perl 6's) OO system is that the complexity is in the
right place -- tucked away where most people don't have to worry about it until
they want to do something complex.
> sub children {
> my $self = shift;
> if ( caller->isa( __PACKAGE__ ) || $self->isa( scalar(caller) ) ) {
> return wantarray ? @{$self->{_children}} : $self->{_children};
> }
> else {
> return @{$self->{_children}};
> }
> }
>
> This is in a vain attempt to implement a protected subroutine. In
> fact, I really want a private writing accessor with a public reading
> accessor, but have absolutely no way to implement that.
>
> Why do I want such a beast? Because I want to GUARANTEE in an absolute
> kind of way that, unless my user truly intended to do so, he's not
> going to be able to accidentally screw up my internal state.
And when your user does want to, essentially say "Nah, you screwed up designing
that object protocol, children shouldn't've been protected." it's the work of a
moment to write:
thing.send(:children, *args)
> (Oh, and Ruby has first-class block. W00T!)
And continuations. But continuations are scary. Good scary, but still scary.
Rob Kinyon
> that object protocol, children shouldn't've been protected." it's the work of a
> moment to write:
>
> thing.send(:children, *args)
I told you I'm still learning. I hadn't gotten to that part of the Pickaxe. :-/
> > (Oh, and Ruby has first-class block. W00T!)
>
> And continuations. But continuations are scary. Good scary, but still scary.
First-class blocks make continuations and coros almost neglible to
implement from an API perspective. Almost makes me wonder how much
trouble it would be to implement this in P5 ...
Rob
Michele Dondi
>> Whatever, the new system by contrast seems to me to be at least 400%
>> more complex, but it won't buy me 400% more functionality.
>
> It will buy you 400% in saving typing, 4000% in less debubbing and
> 40000% in maintainability(==readability).
Of course drawing any figure on such loose terms as I did in the first
place is not serious and I didn't meant it to be, using them more for
illustrational purposes reflecting my own perception.
But the point is: are you sure that you have a 40k% gain in readability?
That's quite a number!! And the impression I have, that I'm trying to
stress once more (but the last time!) is that trying to "stuff everything"
in the signature system is not increasing it any more and that a
_slightly_ simpler one would do instead.
On Fri, 4 Nov 2005, Rob Kinyon wrote:
> So, for a bit of extra complexity, I get peace of mind for myself and my
> users.
The point being, and I'm stressing it once again but no more than once,
that maybe we're adding two bits of extra complexity, whereas just one bit
not only would have been enough, but would have bought you even more peace
of mind. Then again: this is a _feeling_ I got e.g. by reading the
appearently endless discussions about the specifications of sub
parameters, which seem to ensue inherent technical difficulties having to
do with the attempt _conciliate_ too many different paradigms.
Michele
--
If memory serves, Prof. Hermann Zapf considered using Palatino for his wedding
invitation (but reconsidered and used one of his wife's designs instead ---
there's a lesson in that I guess).
- William Adams in comp.text.tex, "Re: Simple Wedding Invitations in LaTeX2e"
Rob Kinyon
> On Fri, 4 Nov 2005, Rob Kinyon wrote:
>
> > So, for a bit of extra complexity, I get peace of mind for myself and my
> > users.
>
> The point being, and I'm stressing it once again but no more than once,
> that maybe we're adding two bits of extra complexity, whereas just one bit
> not only would have been enough, but would have bought you even more peace
> of mind. Then again: this is a _feeling_ I got e.g. by reading the
> appearently endless discussions about the specifications of sub
> parameters, which seem to ensue inherent technical difficulties having to
> do with the attempt _conciliate_ too many different paradigms.
Honestly? I skip about 50% of the discussions on this list. I don't
care about most of the syntax discussions and I don't care about sub
signatures. Well, I -DO- care, just not enough to wrangle about it.
All I care about is "Can I do what I want to do in an easy fashion?"
That's why I spent so much time on roles and why I've released
Perl6::Roles to CPAN. (Well, that was for DBI-2, but I can claim it
was for me, right?) The point is that I will not use a lot of the
features in Perl6, just like I didn't use alot of the features in
Perl5. I doubt I'll ever use PGE directly (though macros will be nice,
once I figure out where I'd use them). Same with most of the
subroutine types.
Though, I do find the complexity reassuring. I like having the
options, even though I will never use them. The alternative is Perl5,
where you can do (almost) anything you could want, except you have you
jump through lots of hoops and you end up with something that works,
but really really slowly. No-one wants that.
Rob
Andrew Rodland
> On 11/7/05, Michele Dondi <bla...@pcteor1.mi.infn.it> wrote:
> > On Fri, 4 Nov 2005, Rob Kinyon wrote:
> > > So, for a bit of extra complexity, I get peace of mind for myself and
> > > my users.
> >
> > The point being, and I'm stressing it once again but no more than once,
> > that maybe we're adding two bits of extra complexity, whereas just one
> > bit not only would have been enough, but would have bought you even more
> > peace of mind. Then again: this is a _feeling_ I got e.g. by reading the
> > appearently endless discussions about the specifications of sub
> > parameters, which seem to ensue inherent technical difficulties having to
> > do with the attempt _conciliate_ too many different paradigms.
>
> Though, I do find the complexity reassuring. I like having the
> options, even though I will never use them. The alternative is Perl5,
> where you can do (almost) anything you could want, except you have you
> jump through lots of hoops and you end up with something that works,
> but really really slowly. No-one wants that.
But it's not such a black-and-white thing. If 1 bit of complexity covers 90%
of cases, 10 bits gets you 99%, 100 bits gets you 99.9%, and so on, where do
you stop? Where do you say "okay, I think we're doing good enough, let's not
add more complexity" ? Especially when that complexity isn't optional. I
think that's really a common "fear", that Perl 6 is going well beyond that
point of sensibility.
If you want to get into personal beliefs, I think that function signatures are
such a complexity quagmire -- and that they're line-noise ugly to boot.
Andrew
Mark Reed
> Especially when that complexity isn't optional. I
> think that's really a common "fear", that Perl 6 is going well beyond that
> point of sensibility.
>
> If you want to get into personal beliefs, I think that function signatures are
> such a complexity quagmire -- and that they're line-noise ugly to boot.
But the ugly and complex bits of function signatures are completely
optional. In the usual case, you can just say
sub foo($x, $y) { do stuff with $x and $y }
Or
method foo($x, $y) { default invocant name used to do stuff with $x and $y }
And not have to worry about it.
Juerd
> If you want to get into personal beliefs, I think that function signatures are
> such a complexity quagmire -- and that they're line-noise ugly to boot.
The nice thing about signatures is that they let you write what you
mean. This saves you an entire translation from what you mean to some
Perl code that manipulates @_. This translation is hard, and error
prone, as is the code that comes from it.
I think that even without any introduction to the subtleties of
signatures, any newbie with some programming experience will instantly
understand the essence of:
sub my_join ($sep, *@elems) {
foo($sep, @elems);
}
and
method connect ($host, $port = 80) { ... }
While this isn't quite so clear:
sub my_join {
my $sep = shift;
foo($sep, @_);
}
sub connect {
croak "..." if @_ < 1;
croak "..." if @_ > 2;
my ($host, $port) = @_;
$port = 80 if not defined $port;
...
}
Or let's take this simple example:
sub convert (:$from, :$to, :$thing) { ... }
That isn't quite "my %args = @_;". Yes, that works, but the only real
way we keep doing it is that the full solution sucks in plain Perl 5:
sub convert {
croak "..." if (@_ % 2) != 0;
my %args = @_;
croak "..." if not exists $args{from};
croak "..." if not exists $args{to};
croak "..." if not exists $args{thing};
my $from = delete $args{from};
my $to = delete $args{to};
my $thing = delete $args{thing};
croak "..." if keys %args;
...
}
before you shout that I'm doing something wrong, yeah, I've been out of
this game for a while. Which only strengthens my point: it's hard to do
it right in Perl 5!
So, the typical answer is: use a module! Good idea, really, but that
still doesn't fix the problem. There are several modules out there that
handle argument parsing, that in practice you need to know the
subtleties of each of them. And none lets you combine scalar and list
context, because only prototypes can do that. I don't have to explain
why prototypes suck, and I think you can guess why combining them with a
parsing module sucks too.
For fun, one example with Params::Check:
use Params::Check qw(check);
sub convert {
croak "..." if (@_ % 2 ) != 0;
my %args = @_;
check(
{
from => { required => 1, store => \my $from },
to => { required => 1, store => \my $to },
thing => { required => 1, store => \my $thing },
},
\%args,
1,
);
...
}
And oh boy, would this all have been VERY different if I wanted to
simulate this instead:
sub convert (:$from, :$to, :$thing is rw) { ... }
I think the complexity of signatures is much less than that of doing the
same things without them, with the extra benefit that even beginners
will (almost) instantly understand most of it!
Larry Wall
: Or let's take this simple example:
:
: sub convert (:$from, :$to, :$thing) { ... }
:
: That isn't quite "my %args = @_;". Yes, that works, but the only real
: way we keep doing it is that the full solution sucks in plain Perl 5:
:
: sub convert {
: croak "..." if (@_ % 2) != 0;
: my %args = @_;
: croak "..." if not exists $args{from};
: croak "..." if not exists $args{to};
: croak "..." if not exists $args{thing};
: my $from = delete $args{from};
: my $to = delete $args{to};
: my $thing = delete $args{thing};
: croak "..." if keys %args;
: ...
: }
:
: before you shout that I'm doing something wrong, yeah, I've been out of
: this game for a while. Which only strengthens my point: it's hard to do
: it right in Perl 5!
Okay, I won't shout (not even on PerlMonks :-), but named parameters
default to optional, so you'd have to write that as
sub convert (:$from!, :$to!, :$thing!) { ... }
in the current scheme of things.
Larry
Rob Kinyon
> default to optional, so you'd have to write that as
>
> sub convert (:$from!, :$to!, :$thing!) { ... }
>
> in the current scheme of things.
Either way, the point is still that the benefits FAR outweigh any
additional complexity. Ruby could benefit from this, too. (While
first-class blocks rock my world, the weird subroutine signature stuff
most certainly doesn't.)
Rob
Andrew Rodland
> Andrew Rodland skribis 2005-11-07 13:30 (-0500):
> > If you want to get into personal beliefs, I think that function
> > signatures are such a complexity quagmire -- and that they're line-noise
> > ugly to boot.
>
> The nice thing about signatures is that they let you write what you
> mean. This saves you an entire translation from what you mean to some
> Perl code that manipulates @_. This translation is hard, and error
> prone, as is the code that comes from it.
Sorry, I wasn't clear here, so I hope you don't mind my cutting you off. What
I meant wasn't "signatures are too much complexity" -- they're not; they're
simply doing something useful -- but rather "too much complexity is getting
thrown into signatures" to the point where the gain isn't so much, but the
complexity starts creeping in, and you need a book just for everyday tasks.
Combined with what seems to me like a thoroughly unreadable syntax, function
signatures are starting to look like a brand new version of the regex mess
that p6 ditched in favor of the more consistent, more readable patterns.
I'm going to stop going on about this one way or another, but I just wanted to
make myself clear first.
Andrew
Jonathan Scott Duff
> Sorry, I wasn't clear here, so I hope you don't mind my cutting you off. What
> I meant wasn't "signatures are too much complexity" -- they're not; they're
> simply doing something useful -- but rather "too much complexity is getting
> thrown into signatures" to the point where the gain isn't so much, but the
> complexity starts creeping in, and you need a book just for everyday tasks.
> Combined with what seems to me like a thoroughly unreadable syntax, function
> signatures are starting to look like a brand new version of the regex mess
> that p6 ditched in favor of the more consistent, more readable patterns.
Well, just to point out that we didn't know a priori that the regexp
syntax was a mess until we got extensive experience with it and with
what we wanted from it. In the early 1990s, perl and its regular
expressions were the coolest stuff ever. :-)
I think the same holds for signature syntax. @Larry are doing the best
juggling act they can to get it worked out such that once it's "set in
stone", the signature syntax will be intuitive, sensible, unobtrusive,
etc. There may be complexity, but most times you shouldn't see it unless
you want to do something strange and wonderous and magical.
The only reason it looks like there's complexity now is because we're
pushing and prodding the signature syntax to see what works and what
doesn't. (At this point, I'm *really* glad the language design is taking
years) Because of this there will be times when all of the guts are
exposed, but I don't think that it'll always be that way. By the time
perl 6.0.0 rolls around, the guts should be tucked away nicely.
my two cents,
-Scott
--
Jonathan Scott Duff
du...@pobox.com
Juerd
> Okay, I won't shout (not even on PerlMonks :-), but named parameters
> default to optional, so you'd have to write that as
> sub convert (:$from!, :$to!, :$thing!) { ... }
> in the current scheme of things.
Ah, thanks.
I hadn't noticed this change, but I like it.
I've updated the PM node :)
Piers Cawley
> First-class blocks make continuations and coros almost neglible to
> implement from an API perspective. Almost makes me wonder how much
> trouble it would be to implement this in P5 ...
Um... tosh. Seriously. Full continuations need some fairly serious retooling of
the call stack if they are to work properly. And one shot continuations are the
next best thing to useless.
Nicholas Clark
> I have been meaning to do some kind of p5 prototype of this, I can
> push it up the TODO list if it would help you.
As you can probably infer from the amount of time that it has taken for me
to realise that I've failed to reply to you, I think that I already have
rather too much going on to be able to take advantage of anything in the
near future. So thanks for the offer, but please do thinks in the order that
is most logical to you.
Nicholas Clark