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
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 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 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 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: 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: 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: $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: $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.
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: 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 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
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 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
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 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
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
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
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
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
-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?
$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: $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: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
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: 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: $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
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
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
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
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 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
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
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 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
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
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,
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
