Re: syntax for accessing multiple versions of a module
On Tue, Oct 18, 2005 at 07:38:19PM -0400, Stevan Little wrote: > 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
Re: $1 change issues [was Re: syntax for accessing multiple versions of a module]
On Thu, 2005-10-20 at 17:12 -0700, Nate Wiger wrote: > 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
Fwd: $1 change issues [was Re: syntax for accessing multiple versions of a module]
Feh - I really need to get on gmail's case for providing a keystroke for "Reply to All". Rob -- Forwarded message -- From: Nate Wiger <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
Re: $1 change issues [was Re: syntax for accessing multiple versions of a module]
On 2005-10-21 1:54 PM, "Nate Wiger" <[EMAIL PROTECTED]> wrote: > 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.
Re: $1 change issues [was Re: syntax for accessing multiple versions of a module]
Luke Palmer wrote: 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. 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. 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
Re: syntax for accessing multiple versions of a module
On Thu, Oct 20, 2005 at 09:14:15PM -0400, John Adams wrote: > From: Luke Palmer <[EMAIL PROTECTED]> > > > But $1 in Perl 5 wasn't the same as $1 in a shell script. > > 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 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
Re: syntax for accessing multiple versions of a module
-Original Message- From: "Patrick R. Michaud" <[EMAIL PROTECTED]> >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.
Re: $1 change issues [was Re: syntax for accessing multiple versions of a module]
On Thu, 20 Oct 2005, 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. (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)
Re: $1 change issues [was Re: syntax for accessing multiple versions of a module]
On 10/21/05, Luke Palmer <[EMAIL PROTECTED]> wrote: > On 10/21/05, Benjamin Smith <[EMAIL PROTECTED]> 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
Re: $1 change issues [was Re: syntax for accessing multiple versions of a module]
On 10/21/05, Benjamin Smith <[EMAIL PROTECTED]> 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. 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
Re: $1 change issues [was Re: syntax for accessing multiple versions of a module]
On Thu, Oct 20, 2005 at 06:39:34PM -0600, Luke Palmer wrote: > On 10/20/05, Nate Wiger <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED], [EMAIL PROTECTED]>
Re: $1 change issues [was Re: syntax for accessing multiple versions of a module]
On Thu, Oct 20, 2005 at 05:12:32PM -0700, Nate Wiger wrote: > 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 [EMAIL PROTECTED]
Re: syntax for accessing multiple versions of a module
From: Luke Palmer <[EMAIL PROTECTED]> > 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.
Re: syntax for accessing multiple versions of a module
On 10/20/05, John Adams <[EMAIL PROTECTED]> wrote: > 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
Re: $1 change issues [was Re: syntax for accessing multiple versions of a module]
On 10/20/05, Nate Wiger <[EMAIL PROTECTED]> wrote: > Luke Palmer wrote: > > > > 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: 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
$1 change issues [was Re: syntax for accessing multiple versions of a module]
Luke Palmer wrote: 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
Re: syntax for accessing multiple versions of a module
-Original Message- From: Luke Palmer <[EMAIL PROTECTED]> > 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?
Re: syntax for accessing multiple versions of a module
On 10/20/05, Nate Wiger <[EMAIL PROTECTED]> wrote: > 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. 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.
Re: syntax for accessing multiple versions of a module
Luke Palmer wrote: On 10/20/05, Nate Wiger <[EMAIL PROTECTED]> 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". 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 [EMAIL PROTECTED] 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
Re: syntax for accessing multiple versions of a module
On 10/20/05, Nate Wiger <[EMAIL PROTECTED]> 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". 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 [EMAIL PROTECTED] Luke
Re: syntax for accessing multiple versions of a module
Nicholas Clark 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". 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
Re: syntax for accessing multiple versions of a module
> 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. 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
Re: syntax for accessing multiple versions of a module
On Thu, Oct 20, 2005 at 11:31:03AM -0700, Nate Wiger 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". 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
Re: syntax for accessing multiple versions of a module
Rob Kinyon wrote: On 10/20/05, Nate Wiger <[EMAIL PROTECTED]> 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
Re: syntax for accessing multiple versions of a module
On 10/20/05, Nate Wiger <[EMAIL PROTECTED]> 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. > 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
Re: syntax for accessing multiple versions of a module
On 10/20/05, Nate Wiger <[EMAIL PROTECTED]> wrote: > 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
Re: syntax for accessing multiple versions of a module
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? 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
Re: syntax for accessing multiple versions of a module
On Wed, Oct 19, 2005 at 03:58:17PM -0700, Nate Wiger wrote: : 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
Re: syntax for accessing multiple versions of a module
On Wed, Oct 19, 2005 at 09:12:47PM -0400, Rob Kinyon wrote: : On 10/19/05, Nate Wiger <[EMAIL PROTECTED]> wrote: : > 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? 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
Re: syntax for accessing multiple versions of a module
On 10/19/05, Nate Wiger <[EMAIL PROTECTED]> wrote: > 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
Re: syntax for accessing multiple versions of a module
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. : 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
Re: syntax for accessing multiple versions of a module
On Wed, Oct 19, 2005 at 03:10:13PM -0700, Nate Wiger wrote: : 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
Re: syntax for accessing multiple versions of a module
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. 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
Re: syntax for accessing multiple versions of a module
On Wed, Oct 19, 2005 at 01:30:07PM -0700, Nate Wiger wrote: : Stevan Little wrote: : >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. 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
Re: syntax for accessing multiple versions of a module
Stevan Little wrote: 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
Re: syntax for accessing multiple versions of a module
On Wed, Oct 19, 2005 at 09:33:39AM -0400, Stevan Little wrote: : 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. 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, 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
Re: syntax for accessing multiple versions of a module
On Wed, Oct 19, 2005 at 09:33:39AM -0400, Stevan Little wrote: > 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 [EMAIL PROTECTED]
Re: syntax for accessing multiple versions of a module
On Wed, Oct 19, 2005 at 12:59:34PM +0200, Ruud H.G. van Tol wrote: : Larry Wall: : : > 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. 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
Re: syntax for accessing multiple versions of a module
Larry, 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
Re: syntax for accessing multiple versions of a module
Larry Wall: > 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
Re: syntax for accessing multiple versions of a module
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. : 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
Re: syntax for accessing multiple versions of a module
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
Re: syntax for accessing multiple versions of a module
> 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. 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
Re: syntax for accessing multiple versions of a module
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 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 On Oct 18, 2005, at 5:41 PM, Nicholas Clark wrote: Sorry if I'm asking a question that I've missed in a synopsis. 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
Re: syntax for accessing multiple versions of a module
On 10/18/05, Juerd <[EMAIL PROTECTED]> wrote: > 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
Re: syntax for accessing multiple versions of a module
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; Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html