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: $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
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: : 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 :asNewCat, 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
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
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:
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
syntax for accessing multiple versions of a module
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
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
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
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
