Re: new sigil
Sam Vilain wrote: ps, X11 users, if you have any key bound to "AltGr", then "AltGr" + C might well give you a ¢ sign without any extra reconfiguration. For me AltGr + C gives Copyright-symbol "©". (SuSe 9.1, tested in konsole, kwrite and thunderbird) -- Markus Laire
Re: new sigil
Steve Peters <[EMAIL PROTECTED]> wrote: > ~ seems to be available for a sigil, if my reading of S02 is correct, and > the cent sign is replacing :: in all cases. If not (that is $::foo is > still the global variable named foo) then * may also be available. Sigils can't conflict with unary operators (like, say, the stringification and flattening operators, ~ and *) and ideally shouldn't conflict with binary ops either (although % breaks this rule). This has been done before several times on p6l, but I'll do it again: Chr TermOperator === ~ Stringify Concatenate ` Reserved for user Reserved for user ! Not @ Array sigil Array sigil # Comment Comment $ Scalar sigilScalar sigil % Hash sigil Hash sigil, modulo ^ (Not sure) one() junction & Subroutine sigilall() junction * Unary splat Multiplication ( Open paren Subroutine call ) (technically unused)Close paren - Negate Subtract _ Identifier (technically unused) = Iteration Assign + Numify Add \ Take reference | any() junction [ Anonymous array Array index { Block Hash index ] (technically unused)Close square bracket } (technically unused)Close curly bracket ; (technically unused)Statement delimiter, anonymous array : Pair"super comma" ' Single quotes (technically unused) " Double quotes (technically unused) , (technically unused)List items < quote words Less than . Method call on topicMethod call > (technically unused)Greater than / Anonymous rule Divide ? Boolify There are very few unary operators available, and none (besides the user-defined backticks operator) unused in both term and operator context. -- Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> Perl and Parrot hacker
Re: new sigil
On Thu, Oct 20, 2005 at 10:40:44PM -0400, Rob Kinyon wrote: > > Surely you aren't suggesting that these non-English speakers do not have > > access to the ASCII (or EBCDIC) character sets for their editors, are you? > > Surely you aren't suggesting that your editor doesn't have access to > the Latin-1 charset, are you? Let's take a look at popular editors: > vi - check > emacs - check > eclipse - check > mutt - check (http://www.rano.org/mutt.html) > Notepad - check > A bazillion other editors - check > (http://www.alanwood.net/unicode/utilities_editors.html) Not every installed version of the above can handle Latin-1 by default. Since many programmers have little control over their installed software, this remains an issue. Also, the ability to do this within the application is not well documented within many editors. Finally, most will of the above allow you to paste in Latin-1 or even UTF-8 data, but the ability to actually enter it from a keyboard using the editor is a completely different issue. > > As I mentioned earlier, most programmers in a corporate environment have > > limited access to system settings. Changing them in some cases can cause > > reprimands or dismissal. Systems are often set up with the bare minimum > > of locales and character sets necessary to do the job. Also, you have to > > deal with the situations where programmers are connecting to *nix servers > > through a variety of Windows-based XWindows servers (Exceed, Cygwin, etc.) > > complicates what character sets are available immensely. > > I have worked as a contractor in almost a dozen settings, most of them > corporate lockdowns, and I've always been able to go to my manager and > say "To be more productive, I need this tool" and it would be loaded > the next day. The few times I've had to talk to an IT person to > explain the tool, I'd do it over lunch (my treat) and it would be on > my desktop the next morning. Saying you cannot get a tool you need > loaded on your machine is, essentially, saying that you cannot play > corporate politics. I'm assuming you can, which means this is a straw > man. I don't think a programmer's skill (or lack thereof) in corporate politics should be a prerequisite to experimenting in Perl 6. My bigger point is about system settings which are typically locked down and not usually sweet-talkable. Also, getting new software purchased can be a painfully slow depending on the bureaucracy involved, and generally requires lots of beers and lunches, or the right catastrophe, which could have been prevented and/or repaired with the tool you want, to speed up the process. Steve Peters [EMAIL PROTECTED]
Re: $1 change issues [was Re: syntax for accessing multiple versions of a module]
On Thu, Oct 20, 2005 at 05:12:32PM -0700, Nate Wiger wrote: > Every regex engine in every language uses $1 or \1. This includes Java, > JavaScript, C, PHP, Python, awk, sed, the GNU regex libs, etc. Somehow > other languages seem ok with this, because it's a widely-used convention. This quibbling over $0 and $1 seems like rampant bikeshedding to me. Given that @Larry has said that $0, $1, etc. correspond to $/[0], $/[1], etc, if you want to keep $1 as the "first parenthesized part", then come up with a compelling, concrete proposal for what to do with $/[0] (and $0) keeping in mind that @array = /(foo)(bar)(baz)/; has to do the right thing. > That's not my wish; just that it's time to take "another look" at the > list of changes to see where the real-world benefit is. IMHO, self consistency is far and away more important than consistency with perl5. > If Perl 6 is going to be successful, this means it must change the > fewest key things with the most benefits. This may mean some things that > "aren't quite perfect" still don't get changed. (It also means lots of > new stuff can still be added - I'm just talking change.) I don't understand this. Change the fewest "key things" relative to what? Perl5? If so, why? Is it not enough that perl5 programs will still compile and run under perl6? > Just food for thought... maybe I'm wrong... I don't know about wrong, but you're certainly entering the game a little late. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: new sigil
> Please let that the sigil looks like a certain leter not be a reason. > > > Juerd They make for good mnemonics, which isn't necessarily a bad thing for people coming from languages without them or with fewer - sebastian
Re: new sigil
> Surely you aren't suggesting that these non-English speakers do not have > access to the ASCII (or EBCDIC) character sets for their editors, are you? Surely you aren't suggesting that your editor doesn't have access to the Latin-1 charset, are you? Let's take a look at popular editors: vi - check emacs - check eclipse - check mutt - check (http://www.rano.org/mutt.html) Notepad - check A bazillion other editors - check (http://www.alanwood.net/unicode/utilities_editors.html) > I have worked on an app that needed to work with English (US and GB), > German, and Japanese. I do not, however, remember having to write my > code in anything but ASCII. No, I had to edit my -templates- and -data files- that included French text. Some of them could use HTML entities, but the datafiles intended for the DB couldn't. > As I mentioned earlier, most programmers in a corporate environment have > limited access to system settings. Changing them in some cases can cause > reprimands or dismissal. Systems are often set up with the bare minimum > of locales and character sets necessary to do the job. Also, you have to > deal with the situations where programmers are connecting to *nix servers > through a variety of Windows-based XWindows servers (Exceed, Cygwin, etc.) > complicates what character sets are available immensely. I have worked as a contractor in almost a dozen settings, most of them corporate lockdowns, and I've always been able to go to my manager and say "To be more productive, I need this tool" and it would be loaded the next day. The few times I've had to talk to an IT person to explain the tool, I'd do it over lunch (my treat) and it would be on my desktop the next morning. Saying you cannot get a tool you need loaded on your machine is, essentially, saying that you cannot play corporate politics. I'm assuming you can, which means this is a straw man. Rob
Re: new sigil
On Thu, Oct 20, 2005 at 04:23:44PM -0600, Luke Palmer wrote: > On 10/20/05, Steve Peters <[EMAIL PROTECTED]> wrote: > > Like the old joke goes "Doctor, Doctor, it hurts when I try to type a > > Latin-1 > > character." "So don't try to type Latin-1 characters!" Instead, many > > programmers will to use the ASCII equivolents that will require additional > > keystrokes. > > You mean additional keystroke. We haven't yet developed any ASCII > equivalent that takes more than two characters. For most cases, the > ASCII equivalents are easier to type than the Latin-1 versions. > However, being a Perl 6 programmer myself, I still use the Latin-1 > versions because I like how they look and feel better. But nobody is > forcing you to do the same. But I may have to support your code. That's the issue. > > The one thing you have to worry about is if you use an editor that > doesn't support Latin-1 to read somebody else's code. However, many > many popular editors are capable of doing this, and any editor that > doesn't probably will soon. We've been over this and over this. I'd say a lot more editors support ASCII than Latin-1. Also, you are also assuming that programmers have control over what tools they have available, and have the ability to upgrade whenever they wish. I've found this to be very far from reality. I understand that the ability to process the code as Unicode is an important feature of Perl 6. There is a big difference between allowing it and requiring it. Writing off a large number of editors, and even operating systems, seems like a big shot in the foot. My biggest concern, however, relates to advocacy. There will need to be books, magazine articles, tutorials, etc. written to announce the arrival of Perl 6. If the code uses Latin-1 characters, and people are unable to look at the example code in their favorite editor or type in some of the example code, we'll lose that person to Perl 6. The other alternative is to preface every article with the explanation of the separate ASCII/Latin-1 sigils. That doesn't sound practical, and cannot be policed or enforced. > > Also, don't think of the class sigil as a sigil. You won't be writing > it very often. Just think of it as an operator. > > My final point: we don't introduce unicode characters lightly. We do > so when we think it is the best symbol for the job, optimizing, for > once, for readability rather than writability. As you mentioned above, readibility is a big issue. If I can't tell one sigil from another, or cannot even see it, how can I support the code? > If you don't think the > class sigil should be a unicode character, come up with a better one. > We're not going to say "You're right, Steve. No more unicode sigils!" > until wee see a good alternative to the unicode sigil that we have. ~ seems to be available for a sigil, if my reading of S02 is correct, and the cent sign is replacing :: in all cases. If not (that is $::foo is still the global variable named foo) then * may also be available. Steve Peters [EMAIL PROTECTED]
Re: new sigil
Schneelocke skribis 2005-10-21 1:07 (+0200): > I think the reason why Larry proposed the "¢" is much simpler - it > looks a bit like a c, which one could associate with "class", similar > to how $ looks like S (scalar) and @ looks like a (array). :) And how % looks like h (hash). I dislike things like "$calar" and "@rray", and now some people will use "¢lass" in examples. Please let that the sigil looks like a certain leter not be a reason. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: new sigil
On 10/20/05, Steve Peters <[EMAIL PROTECTED]> wrote: > As I mentioned earlier, most programmers in a corporate environment have > limited access to system settings. And in those kinds of corporate environments, you're not going to be working with any code but code written in-house. Which means that nobody is going to be using Latin-1, and everyone will be using the ASCII synonyms. What's the problem? Please, just use the ASCII synonyms. We've argued over the unicodity of Perl 6 many times; you're certainly not the first with this concern. The result every time is: Unicode will be in Perl 6, nobody is forcing you to use it. Luke
Re: new sigil
On Thu, Oct 20, 2005 at 05:03:27PM -0400, Rob Kinyon wrote: > On 10/20/05, Steve Peters <[EMAIL PROTECTED]> wrote: > > I have some serious concerns about using Latin-1 sigils within Perl 6 and > > the ASCII multi-character aliases. Am I not understanding something that > > I should see this as an advantage? > > I had the same concern a few months back. I've come to see the light > in this fashion: > 1) more and more Perl programmers come from non-English countries. > Heck, the Pugs effort is at least 50% non-US, if not more. None of the > are on US soil and very few of the leaders are US citizens. Surely you aren't suggesting that these non-English speakers do not have access to the ASCII (or EBCDIC) character sets for their editors, are you? > 2) More and more of us are programming with internationalization > (i18n) in mind. Just recently, I had to edit french text within the > templates of an app I work on. If you haven't already, you will be > doing so in the near future, within the next 3 years. I have worked on an app that needed to work with English (US and GB), German, and Japanese. I do not, however, remember having to write my code in anything but ASCII. > 3) Every editor (with very few exceptions) can display Latin-1 > and, with a few more exceptions, can input Latin-1. If your favorite > editor cannot, then that's something to bring up with the authors. As I mentioned earlier, most programmers in a corporate environment have limited access to system settings. Changing them in some cases can cause reprimands or dismissal. Systems are often set up with the bare minimum of locales and character sets necessary to do the job. Also, you have to deal with the situations where programmers are connecting to *nix servers through a variety of Windows-based XWindows servers (Exceed, Cygwin, etc.) complicates what character sets are available immensely. Also, what settings changes do I need to make to get Latin-1 on ? Welcome to your documentation nightmare! In Perl 5, we have a nearly impossible time keeping track of where Microsoft has put their free compiler tools. Now multiply that by the number of Linux distributions, BSD distributions, and various other operating systems. Don't forget different versions will do it differently, and have documentation in different places. Some of the documentation won't even be available on the Internet, so Perl 6 would need to reference it in some way. Are you beginning to get the magnitude of the documentation problem? > > Windows ... yeah. As you pointed out, the old joke goes "Doctor, > it hurts when I use Windows . . . then, don't use Windows!" Well over 95% of the desktop computers in a corporate environment are using Windows. If you are suggesting Perl 6 ignores Windows, then we should all start writing Perl 6's obituary. This sort of attitude does nothing to advance Perl 6. > With the availability of dual-booting into FreeBSD/Linux (given the > near-complete migration of all the necessary Office products) and both > gvim and emacs having been successfully ported to WIn32, there is a > way to do it. gvim on WinXP will do all Latin-1 charset with the vim > keys. (I don't know about emacs, but I'd be shocked if it didn't.) If > your IT department's policy is rigid, a quick discussion with your > manager's manager will solve that problem immediately. Or, the cost of > a few lunches with your favorite IT person will exempt your computer > from the nightly audit. ($50 goes a long way ...) > Again, I'd prefer not to be fired. Everything you have written above is not an option for the majority of the programmers out there. Also, not to helpful if you write your programs in TSO on an IBM mainframe. > Personally, I plan on using every single Latin-1 operator I am > given access to. All the cool kids will ... Famous last words have never been more finely spoken. Ignoring Windows and other environments without ready access to Latin-1 seems like a horrible mistake to me. While the cool kids are playing with their Latin-1 sigils, programmers in corporate environments where Latin-1 isn't available will start writing their new systems in Java, Ruby, or .NET. Steve Peters [EMAIL PROTECTED]
Re: syntax for accessing multiple versions of a module
From: Luke Palmer <[EMAIL PROTECTED]> > But $1 in Perl 5 wasn't the same as $1 in a shell script. Sure--but that's not what I said. I'm all for breaking things that need breaking, which is why I keep my mouth shut most of the time--either I see the reason or I suspect (that is, take on faith, which is okay by me) there's a reason I don't see or fully understand. I'm just not seeing a compelling reason for this one, and a pretty good reason not to do it: I'm not aware offhand of any other place where $0 is used in regex matching, and several of the languages which you point out are zero-based in other places are not zero-based in regex matching.
Re: syntax for accessing multiple versions of a module
On 10/20/05, John Adams <[EMAIL PROTECTED]> wrote: > Then the target audience is specifically not people coming from a > shell scripting background, who are quite used to the idea that $0 is > different from $1 in a way in which $1 is not different from $2. > Correct? But $1 in Perl 5 wasn't the same as $1 in a shell script. The shell scripters seemed to be able to substitute $ARGV[0] for $1 pretty well nonetheless. Luke
Re: $1 change issues [was Re: syntax for accessing multiple versions of a module]
On 10/20/05, Nate Wiger <[EMAIL PROTECTED]> wrote: > Luke Palmer wrote: > > > > Okay, I may still be missing your point, so let me try to summarize > > just to be sure we're on the same page: You say that the thing that > > is going to hinder migration to Perl 6 is the fact that it's different > > from Perl 5. > > Intentionally trite oversimplification. Oh, sorry. I was going to expand on that, but then the direction of my message changed and I forgot to. Sorry for my overall hostile tone. I'll try to conduct myself civilly for the rest of the argument. > > Our target audience is only somewhat from a Perl 5 background. People > > from Java, from Python, from C, and even just starting to program will > > be learning Perl 6, and they would rather have all the language be > > zero-based, rather than most of it being zero-based except for $1, $2, > > etc. (you were complaining about special exceptions if I recall). > > Every regex engine in every language uses $1 or \1. This includes Java, > JavaScript, C, PHP, Python, awk, sed, the GNU regex libs, etc. Somehow > other languages seem ok with this, because it's a widely-used convention. Yeah, well, every other regex engine on the planet uses [] for character classes, no other regex engine uses <> for subrules, no other regex engine uses a match object or nested capture numbering. Perl 6's patterns are _not_ regexes anymore. But I doubt that we won't be imitated, because the new regexes are way better than the old ones. Breaking cruft for a reason and all that. > And you don't have to answer, but have you actually programmed in Java > or Python? You seem to be speaking for alot of programmers. Yes, yes. You seem to be speaking for a lot of programmers, too. We have to, for if we didn't try, we probably wouldn't be good language designers. > > The reason I'm dismissing you as a "complainer" is because of your > > broad field of attack. You say that "the method syntax is starting to > > make [your] head spin". Well, what about it is making your head spin? > > The method: infix:<+> stuff makes no sense to me, but I don't want to > dwell on it. Ahh, grammatical categories. You may already know this, but let me try to explain. The category: stuff is our way of letting the user hook into the parser in common ways without them having to go and explicitly change the grammar of the language. Generally, that syntax has nothing to do with it being a method. Whatever you see inside the quoter after the category is always introducing (or defining an additional meaning for) a token, which I guess is why it's quoted. > > The fact that we use . instead of -> (like every other language on > > the planet)? > > You're using my argument for me - thanks. See above. Huh? So you want to go back to Perl 5's arrow? *Anybody* coming to Perl 6 from some non-Perl 5 language is going to be more comfortable with dot. > > [1] Which will be, what, eight hours for a Perl 5 programmer? Have > > you ever spent a month trying to learn, oh, say, Haskell? Because > > people do that, too. > > There are more components to this that just the learning time for one > person. There are project teams, sustaining engineering for existing > projects, etc. And that's not even counting management tape. Real-world, > profitable computing is a big, ugly, nasty beast. Which is why we're going to great lengths to make sure that your Perl 5 code and your Perl 6 code can run together. use perl5:DBI; The transition to Perl 6 doesn't mean that /usr/bin/perl is going to change to version six under your feet and all your code will break. > If Perl 6 is going to be successful, this means it must change the > fewest key things with the most benefits. This may mean some things that > "aren't quite perfect" still don't get changed. (It also means lots of > new stuff can still be added - I'm just talking change.) It sounds like you want a backwards-compatible change. From the outset we knew that this wasn't our goal. Perl 5 is full to the brim with syntax, and there's pretty much nowhere we can add anything, and there's tons of cruft that we had to get rid of. Consider Perl 6 to be a derivative, not an extension, of Perl 5. Luke
$1 change issues [was Re: syntax for accessing multiple versions of a module]
Luke Palmer wrote: Okay, I may still be missing your point, so let me try to summarize just to be sure we're on the same page: You say that the thing that is going to hinder migration to Perl 6 is the fact that it's different from Perl 5. Intentionally trite oversimplification. My problem is that it's different in some ways which are not truly useful, and that cause unnecessary relearning/rewriting/incompatibilities. Our target audience is only somewhat from a Perl 5 background. People from Java, from Python, from C, and even just starting to program will be learning Perl 6, and they would rather have all the language be zero-based, rather than most of it being zero-based except for $1, $2, etc. (you were complaining about special exceptions if I recall). Every regex engine in every language uses $1 or \1. This includes Java, JavaScript, C, PHP, Python, awk, sed, the GNU regex libs, etc. Somehow other languages seem ok with this, because it's a widely-used convention. And you don't have to answer, but have you actually programmed in Java or Python? You seem to be speaking for alot of programmers. The reason I'm dismissing you as a "complainer" is because of your broad field of attack. You say that "the method syntax is starting to make [your] head spin". Well, what about it is making your head spin? The method: infix:<+> stuff makes no sense to me, but I don't want to dwell on it. The fact that we use . instead of -> (like every other language on the planet)? You're using my argument for me - thanks. See above. If you want something to change, you should suggest a change. If you think that Perl 6 is changing too much in general, and that we should go back and make it more like Perl 5, you probably won't get your wish. That's not my wish; just that it's time to take "another look" at the list of changes to see where the real-world benefit is. [1] Which will be, what, eight hours for a Perl 5 programmer? Have you ever spent a month trying to learn, oh, say, Haskell? Because people do that, too. There are more components to this that just the learning time for one person. There are project teams, sustaining engineering for existing projects, etc. And that's not even counting management tape. Real-world, profitable computing is a big, ugly, nasty beast. If Perl 6 is going to be successful, this means it must change the fewest key things with the most benefits. This may mean some things that "aren't quite perfect" still don't get changed. (It also means lots of new stuff can still be added - I'm just talking change.) For example, NIS+ was released as a follow-up to NIS. It was supposed to solve all the issues (mostly security) from NIS. But it was made too complicated, and incompatible with NIS. People were supposed to re-learn NIS and convert all their maps to NIS+. They didn't. Just food for thought... maybe I'm wrong... -Nate
Re: syntax for accessing multiple versions of a module
-Original Message- From: Luke Palmer <[EMAIL PROTECTED]> > Our target audience is only somewhat from a Perl 5 background. People from Java, from Python, from C, and even just starting to program will be learning Perl 6, and they would rather have all the language be zero-based, rather than most of it being zero-based except for $1, $2, etc. Then the target audience is specifically not people coming from a shell scripting background, who are quite used to the idea that $0 is different from $1 in a way in which $1 is not different from $2. Correct?
Re: syntax for accessing multiple versions of a module
On 10/20/05, Nate Wiger <[EMAIL PROTECTED]> wrote: > I think you missed my point(s), but if you feel compelled to write me > off as a "complainer" just because I have a counter-opinion that is at > least somewhat built from a good amount of experience, then I do think > you're wearing a set of blinders to practical issues. Okay, I may still be missing your point, so let me try to summarize just to be sure we're on the same page: You say that the thing that is going to hinder migration to Perl 6 is the fact that it's different from Perl 5. We've known for quite a while that Perl 6 is not merely an "upgrade" to Perl 5. We're designing a different language, but that language is still Perl. Perl 5 is like seventeenth century English, Perl 6 is like twenty-first century English (even though we don't quite know what that is yet). The language changes with the people and the times, and this sometimes means that the results will not be mutually intelligible. Our target audience is only somewhat from a Perl 5 background. People from Java, from Python, from C, and even just starting to program will be learning Perl 6, and they would rather have all the language be zero-based, rather than most of it being zero-based except for $1, $2, etc. (you were complaining about special exceptions if I recall). The reason I'm dismissing you as a "complainer" is because of your broad field of attack. You say that "the method syntax is starting to make [your] head spin". Well, what about it is making your head spin? The fact that we use . instead of -> (like every other language on the planet)? The fact that there are two ways to call a method in Perl 6: $obj.meth($arg) meth $obj: $arg Rather than only two ways from Perl 5: $obj->meth($arg) meth $obj $arg ? The fact that we're declaring methods with "method" instead of "sub"? If you want something to change, you should suggest a change. If you think that Perl 6 is changing too much in general, and that we should go back and make it more like Perl 5, you probably won't get your wish. To a lot of us p6lers, we've been around Perl 6 for a long time, and are starting to speak it natively. It feels right. And we think that when somebody does invest the time to learn it[1], it will start to feel right to them, too. And after those people have been writing in Perl 6 for a year, they will be glad that we optimized for the the Perl 6 programmer, rather than the learning Perl 5 programmer. Luke [1] Which will be, what, eight hours for a Perl 5 programmer? Have you ever spent a month trying to learn, oh, say, Haskell? Because people do that, too.
Re: new sigil
On 21/10/05, Darren Duncan <[EMAIL PROTECTED]> wrote: > On the other hand, if you want to use the ¢ due > to its being conceptually tied to $, that they > are different units of currency meant to be used > together, then the ¢ is fine. I think the reason why Larry proposed the "¢" is much simpler - it looks a bit like a c, which one could associate with "class", similar to how $ looks like S (scalar) and @ looks like a (array). :) -- schnee
Re: new sigil
Speaking briefly, Unicode is the way of the future, and even many modern systems have strong support for it. Perl 6 is a language of the future plus present, not of the past, and shouldn't be limited by things that are only issues for older systems while even then being easy to work-around on them. I say that we should exploit all the Unicode characters reasonably possible to make for a more elegant language, and any tools currently behind will catch up before long. In this case, I support the use of any international currency symbol for use as Perl sigils and/or operators as appropriate. Eg, we already use $ (dollar; unicode=0024; utf8=24) and ¥ (yen; unicode=00A5; utf8=C2A5), and I suggest that the next best one to exploit is ¤ (euro; unicode=20AC; utf8=E282AC), and the next best is £ (pound; unicode=00A3; utf8=C2A3). In my experience, the ¢ (cent; unicode=00A3; utf8=C2A3) is no harder to type than either of those. In some cases, typing a ¢ is easier than most of those characters. On a Macintosh keyboard, typing opt-4 will get a ¢ as shift-4 gets a $. For that matter, Macintosh keyboards and their 'option' key allows one to type twice as many characters without entering special codes or using an input palette as other keyboards having only a 'shift' key do. So in that respect, if you want a sigil that is meant to be discouraged due to being harder to type, then ¢ may be a worse choice than some other options. On the other hand, if you want to use the ¢ due to its being conceptually tied to $, that they are different units of currency meant to be used together, then the ¢ is fine. All this being said, if you explicitly want to have ASCII alternatives for all Unicode characters being used, then I suggest it is best to keep the use of Unicode characters mainly in operators, because those are always surrounded by whitespace and can easily be substituted for latin words. Whereas, because sigils are always right next to ordinary word characters, I suggest that they should always be ASCII characters, or that the ASCII equivalent should not contain any word characters. My impression is that sigils containing alphanumerics just look wrong. Perhaps a solution here for an ASCII equivalent is something combining the $ and something else. How about this twigil, which combines '::' and '$': :$: Does that conflict with anything? -- Darren Duncan
Re: new sigil
On Thu, 2005-10-20 at 08:45 -0700, Larry Wall wrote: > More info. ¢T is a scalar variable just like $T, but enforces a > class view, so you can use it as a class parameter, and pass any > object to it, but only access the classish aspects of the object. > The only other big difference is that you can use it in the class > syntactic slot, so it's legal to say ¢T $x where it would be illegal > to say $T $x. Is this necessary? Isn't putting a variable before another variable like that in the correct context (subroutine declaration, in this case), enough to imply that the variable "does Class" ? While I'm not arguing against another sigil type, I think this would distinguish it from the other sigils % and @, which are just an implicit (does Hash) / (does Array), as well as being a part of the unique name, as I understand it so far. This makes me wonder which language feature is used to describe sigils themselves. Can I define my own sigils with their own type implications? Sam. ps, X11 users, if you have any key bound to "AltGr", then "AltGr" + C might well give you a ¢ sign without any extra reconfiguration.
Re: syntax for accessing multiple versions of a module
Luke Palmer wrote: On 10/20/05, Nate Wiger <[EMAIL PROTECTED]> wrote: $1 is a prime example. $0 means the program name (all scopes). $1 is the first match. It's been that way for a very, very, very long time, and it works just great. There is no *compelling* reason to change this, other than to satisfy a few people that think it "should be different". Thank you for your complaints. Now that we know that for a certain portion of perl users, "Perl 5 works fantastic for 95% of the cases," we have decided to develop a side project. You can join in by subscribing to [EMAIL PROTECTED] Hah, that's clever. I think you missed my point(s), but if you feel compelled to write me off as a "complainer" just because I have a counter-opinion that is at least somewhat built from a good amount of experience, then I do think you're wearing a set of blinders to practical issues. -Nate
Re: new sigil
On 10/20/05, Steve Peters <[EMAIL PROTECTED]> wrote: > Like the old joke goes "Doctor, Doctor, it hurts when I try to type a Latin-1 > character." "So don't try to type Latin-1 characters!" Instead, many > programmers will to use the ASCII equivolents that will require additional > keystrokes. You mean additional keystroke. We haven't yet developed any ASCII equivalent that takes more than two characters. For most cases, the ASCII equivalents are easier to type than the Latin-1 versions. However, being a Perl 6 programmer myself, I still use the Latin-1 versions because I like how they look and feel better. But nobody is forcing you to do the same. The one thing you have to worry about is if you use an editor that doesn't support Latin-1 to read somebody else's code. However, many many popular editors are capable of doing this, and any editor that doesn't probably will soon. We've been over this and over this. Also, don't think of the class sigil as a sigil. You won't be writing it very often. Just think of it as an operator. My final point: we don't introduce unicode characters lightly. We do so when we think it is the best symbol for the job, optimizing, for once, for readability rather than writability. If you don't think the class sigil should be a unicode character, come up with a better one. We're not going to say "You're right, Steve. No more unicode sigils!" until wee see a good alternative to the unicode sigil that we have. Luke
Re: syntax for accessing multiple versions of a module
On 10/20/05, Nate Wiger <[EMAIL PROTECTED]> wrote: > $1 is a prime example. $0 means the program name (all scopes). $1 is the > first match. It's been that way for a very, very, very long time, and > it works just great. There is no *compelling* reason to change this, > other than to satisfy a few people that think it "should be different". Thank you for your complaints. Now that we know that for a certain portion of perl users, "Perl 5 works fantastic for 95% of the cases," we have decided to develop a side project. You can join in by subscribing to [EMAIL PROTECTED] Luke
Re: syntax for accessing multiple versions of a module
Nicholas Clark wrote: $1 is a prime example. $0 means the program name (all scopes). $1 is the first match. It's been that way for a very, very, very long time, and it works just great. There is no *compelling* reason to change this, other than to satisfy a few people that think it "should be different". I cannot agree. The reason you give is not "compelling". On the contrary, doing things "the established way" is perhaps THE most compelling reason. After all, we're changing to "." for objects to be like Java and other languages, right? EVERY other language (including Perl 5) starts with $1 (or \1). Neither is the more important reason, that it regularises the numbers when using an array lookup to find matches, $1 being $/[1], IIRC. If you could provide a real-world example where this helps, I'd appreciate it. Again, I'm being sincere. I have never run into this issue personally, so I'm trying to understand the benefit. -Nate
Re: new sigil
On 10/20/05, Steve Peters <[EMAIL PROTECTED]> wrote: > I have some serious concerns about using Latin-1 sigils within Perl 6 and > the ASCII multi-character aliases. Am I not understanding something that > I should see this as an advantage? I had the same concern a few months back. I've come to see the light in this fashion: 1) more and more Perl programmers come from non-English countries. Heck, the Pugs effort is at least 50% non-US, if not more. None of the are on US soil and very few of the leaders are US citizens. 2) More and more of us are programming with internationalization (i18n) in mind. Just recently, I had to edit french text within the templates of an app I work on. If you haven't already, you will be doing so in the near future, within the next 3 years. 3) Every editor (with very few exceptions) can display Latin-1 and, with a few more exceptions, can input Latin-1. If your favorite editor cannot, then that's something to bring up with the authors. Windows ... yeah. As you pointed out, the old joke goes "Doctor, it hurts when I use Windows . . . then, don't use Windows!" With the availability of dual-booting into FreeBSD/Linux (given the near-complete migration of all the necessary Office products) and both gvim and emacs having been successfully ported to WIn32, there is a way to do it. gvim on WinXP will do all Latin-1 charset with the vim keys. (I don't know about emacs, but I'd be shocked if it didn't.) If your IT department's policy is rigid, a quick discussion with your manager's manager will solve that problem immediately. Or, the cost of a few lunches with your favorite IT person will exempt your computer from the nightly audit. ($50 goes a long way ...) Personally, I plan on using every single Latin-1 operator I am given access to. All the cool kids will ... Rob
Re: new sigil
On Thu, Oct 20, 2005 at 10:24:23AM -0700, chromatic wrote: > On Thu, 2005-10-20 at 10:32 -0500, Steve Peters wrote: > > > The idea of punishing programmers who choose to use certain operating system > > or locales just doesn't seem right to me. > > Haven't they already acclimated to the punishment of those operating > systems already? > I have rarely considered working in Eclipse or WSAD to be a punishment, but I still can't type a Latin-1 sigil on its editor. Here on my OpenBSD box, I can't even cut and paste a Latin-1 sigil here in mutt. There are many things that I get punished for by being required to use Windows at work, but I've not programmed in a language that punishes me for the characters available on my system. Since there have been some concerns regarding the lack of suggestions in this thread, my suggestion is to avoid non-ASCII sigils completely. There are a couple of reasons I see for this. The first reason is efficiency. I started programming with Perl 5 because of its efficiency. The lack of the code-compile-run loop helped to shorten development and feedback times. The fact that I had to go to Google to figure out how to type a cent character doesn't bode well for my efficiency in Perl 6. The best way I can see currently on my current desktop setup is: * Start up Microsoft Word * Type the character as ALT-155 (the 155 must be typed on the numeric keypad) * Copy and paste the character into my editor Like the old joke goes "Doctor, Doctor, it hurts when I try to type a Latin-1 character." "So don't try to type Latin-1 characters!" Instead, many programmers will to use the ASCII equivolents that will require additional keystrokes. Ideally, a lazy programmer will develop shortcuts to make this easier, but this, of course, takes time and the right editor. The second reason is in educating the average programmer. There may be books written on Perl 6 that don't explain the ASCII equivolents for the Latin-1 sigils and vice-versa. If you don't think that will be the case, lets take Perl 5 as the example. There are many beginning Perl 5 books, even those written by reputable authors, that treat "for" and "foreach" very differently, when they are identical in every way. I would hope the book editors will be good enough to catch the sigil differences in Perl 6, but this seems rather naive on my part. These both cause problems with advocacy. The high-end Perl programmers who these sigils are supposed to be for are also, typically, the best advocates and the ones trusted in a typical programming shop. If this programmer has to advocate changes in the entire development environment to get the most efficient environment they can get along with migrating to Perl 6, this programmer is going to have a tough fight, especially when competing against the likes of Java with Eclipse/WSAD or Ruby on Rails. I have some serious concerns about using Latin-1 sigils within Perl 6 and the ASCII multi-character aliases. Am I not understanding something that I should see this as an advantage? Steve Peters [EMAIL PROTECTED]
Re: new sigil
Luke Palmer skribis 2005-10-20 10:07 (-0600): > You seem to be forgetting that we do have the longest token rule. So, > the only way this destroys a dream (and likewise, the only way c| > doesn't work), is if you have the poor package or class name c and you > insist on writing c|d or c!d without spaces. I'd like to be able to use these without whitespace, and I expect it to be commonly written without whitespace for simple cases, because 1|2|3 isn't any less clear than 1 | 2 | 3, while it's a lot easier to type. > Still, if you'd like to make a suggestion instead of just telling us > why our ideas don't work in very specific circumstances, feel free. I've already suggested two. Is that not enough? (a) ^ (b) 1c 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
> Unfortunately many people WILL have to deal with such changes, and > the question should be: Does a given change offer a clear improvement? > As you said, if we're helping %1 of people %1 of the time, are the > other 99% really going to change all their scripts? No chance. You again misread what I said. "The other 99%" aren't even going to notice the changes. Remember - 90% of all Perl code in the wild that should use hashes doesn't. 90% of all Perl code that should use map and grep doesn't. 90% of all Perl code that should use regexes doesn't. The authors of those programs aren't even going to notice that P6 changed. All they're going to see is that there's a few VERY MINOR syntactical changes, they'll adjust, and they'll be happy. Please remember the primary uses of Perl5 - systems administration, package management, and CGI scripts. By far, those are the overwhelming uses of Perl. In fact, I would argue that 99% of all Perl code in the world falls under those three categories. If you don't believe me, read "The Pragmatic Programmer". These are excellent programmers and their view of Perl is for: 1) Writing tests (pp. 53, 197) 2) Project management and glue (pp. 100-101) In fact, they specifically state in Tip 28 that every programmer should learn a "Text Manipulation Language" (the authors prefer Ruby and Perl) in order to do these things. These are "The other 90%" you refer to. They're not going to care one way or the other. And, if they do, /usr/local/bin/perl won't suddenly disappear like Cindarella at the ball, you know. Rob
Re: syntax for accessing multiple versions of a module
On Thu, Oct 20, 2005 at 11:31:03AM -0700, Nate Wiger wrote: > $1 is a prime example. $0 means the program name (all scopes). $1 is the > first match. It's been that way for a very, very, very long time, and > it works just great. There is no *compelling* reason to change this, > other than to satisfy a few people that think it "should be different". I cannot agree. The reason you give is not "compelling". Neither is the more important reason, that it regularises the numbers when using an array lookup to find matches, $1 being $/[1], IIRC. But there are good reasons to change, and better reasons than you state. Nicholas Clark
Re: syntax for accessing multiple versions of a module
Rob Kinyon wrote: On 10/20/05, Nate Wiger <[EMAIL PROTECTED]> wrote: And, it shares alot with other languages people know and use. That's more because languages are incestuous (like Perl) instead of languages independently arriving at the same conclusions. Yes, the "while" loop is going to look the same everywhere. But, the fact that everyone uses $1 to mean the first match has nothing to do with whether or not that's a good idea. The first engine did so, which means the next one probably will. Of course - but that doesn't mean it's a bad thing. It makes Perl more accessible and learnable - and easier to switch between (it is not the only language for many programmers). $1 is a prime example. $0 means the program name (all scopes). $1 is the first match. It's been that way for a very, very, very long time, and it works just great. There is no *compelling* reason to change this, other than to satisfy a few people that think it "should be different". Right now the design is going towards something that's very very un-Perlish from a syntax standpoint. Sure, the philosophy's there, but there are fewer and fewer things Perl 6 shares with Perl 5 (or other widely-used languages). I wholeheartedly disagree. You can take any piece of P5 code and, with very few modifications, have it run as native P6 code. I think it depends on what type of code you have. Maybe for your code this is true, but my view appears a bit different. Frankly, most of the features in P6 look to be usable by 1% of the Perl developers, and then only about 1% of the time. Most of my P6 is going to be very vanilla. I'll take advantage of most of the new list operators and thoroughly abuse the class/role system, but I'm not going to be writing my own grammars or deal with $0/$1/etc. Unfortunately many people WILL have to deal with such changes, and the question should be: Does a given change offer a clear improvement? As you said, if we're helping %1 of people %1 of the time, are the other 99% really going to change all their scripts? No chance. Anyways, don't misread me as a complete naysayer. But I'm lazy and impatient, and am concerned the transition to Perl 6 is not going to suit me. :-) -Nate
Re: syntax for accessing multiple versions of a module
On 10/20/05, Nate Wiger <[EMAIL PROTECTED]> wrote: > And, it shares alot with other languages people know and use. That's more because languages are incestuous (like Perl) instead of languages independently arriving at the same conclusions. Yes, the "while" loop is going to look the same everywhere. But, the fact that everyone uses $1 to mean the first match has nothing to do with whether or not that's a good idea. The first engine did so, which means the next one probably will. > Right now the design is going towards something that's very very > un-Perlish from a syntax standpoint. Sure, the philosophy's there, but > there are fewer and fewer things Perl 6 shares with Perl 5 (or other > widely-used languages). I wholeheartedly disagree. You can take any piece of P5 code and, with very few modifications, have it run as native P6 code. You won't be using a ton of the greatest features, but we have that in P5. I once taught a programmer who'd been using Perl for over a year how to use hashes. I have an article coming up in early November on perl.com about how and why to use subroutines. Just because _you_ know about the feature doesn't mean the hoi-polloi do. Heck, I've been programming in Perl for almost 10 years and I have NEVER written a line of XS. I wouldn't know where to start. Frankly, most of the features in P6 look to be usable by 1% of the Perl developers, and then only about 1% of the time. Most of my P6 is going to be very vanilla. I'll take advantage of most of the new list operators and thoroughly abuse the class/role system, but I'm not going to be writing my own grammars or deal with $0/$1/etc. I don't deal with them now - I prefer named captures. The point is that if you want to truly clean off the cruft, you have to approach with a completely open mind. That open mind is going to piss off a lot of people and you will never do everything you were hoping to do, but the end product will be better off for it. You'll never reach the moon unless you shoot for the stars. Rob
Re: syntax for accessing multiple versions of a module
On 10/20/05, Nate Wiger <[EMAIL PROTECTED]> wrote: > Larry Wall wrote: > > I think there can be some kind of community metainformation that sets > > defaults appropriately. And if not, the site/project can certainly > > establish defaults. On the other hand, a lot of projects do simply > > want to specify the version and author explicitly eveyr time, > > and they'd rather tweak it by hand (or by script) if they want to > > change it, since then at least they know when they need to rerun the > > regression tests. > > I think it's a laudable idea in theory, but not necessarily application. > I've done quite alot of Perl programming, and I've never run into this > personally. Who has? (Really, I'm being serious.) Are there really > multiple modules sharing interchangeable interfaces? Or instances where > we want to allow the same name to mean different concepts depending on > the author? Please see http://www.perlmonks.org/?node_id=501496 for more on the issue of names. My Tree module and Schwern's Tree distro have almost zero interface compatibility. They both represent N-ary trees, except mine exposes the tree interface and Schwern's is just a OO interface for a hash implemented as a tree. My module is descended from Tree::Simple, except ::Simple almost never is. The same thing goes for my version of Tree::Binary and Stevan Little's. Two completely different interfaces, but here we're solving the same problem. The major difference between mine and his is that mine inherits from my Tree whereas his is an independent module. This means that adding transparent persistence (which is what my rewrite does) to his module is a bit of a bear. Hence, you might want to use RKINYON's Tree::Binary over STEVAN's Tree::Binary. Or, what should I call mine? (This is a real question - if you have any suggestions, please let me know!) > There's no logical difference between: > > use DBI:TIMB > use DBI:JEFFSTER > > And: > > use TIMB::DBI > use JEFFSTER::DBI No, this isn't any good, either. I took over DFERRANCE's PDF::Template implementation. He has nothing to do with it anymore. So, DFERRANCE::PDF::Template now becomes RKINYON::PDF::Template? Or, does RKINYON now maintain something in the DFERRANCE namespace? What on earth does the name DFERRANCE provide, except for an additional layer of confusion. > Anyways, I don't like the idea of people being able to upload > identically named modules to CPAN. I think that's a very bad idea. See > Rob Kinyon's message. I think you misinterpreted my message. My point is that uploading things with the same name is a good plan, but it has to be thought through, especially given the points I raised. But, I very much agree that it should happen. I'd like to propose a slight shift in emphasis. I think that more focus needs to be made in project-wide or namespace-wide disambiguation and module aliasing. If I was able to say in my CP6AN distro that I depend on DBI:2.05-:cpan-TIMB and that I'm going to call it DBI, then all the files in my distro should automatically have that alias built in. This means that anyone wanting to use DBI:cpan-JRANDOM in their code can alias it as DBI on a project-wide basis, yet still be able to use my distro and everything be ok. The important thing here, I think, is that while aliasing package names is a lexical action, there can be a larger lexical scope. It may be that we need the concept of a "Project", along with Module, Package, Class, and Role. This way, the Project states "Whenever you load a file that matches the criteria below, apply the following lexical _stuff_." Rob
Re: new sigil
On Thu, 2005-10-20 at 10:32 -0500, Steve Peters wrote: > The idea of punishing programmers who choose to use certain operating system > or locales just doesn't seem right to me. Haven't they already acclimated to the punishment of those operating systems already? -- c
Re: new sigil
What about something like: c\ Then you get sub sametype (c\T $x, c\T $y) {...} Not exactly pretty though. c\T Actualy i think ^ might be my favorite so far. sub sametype (^T $x, ^T $y) {...} -- Eric
Re: new sigil
On Thu, 20 Oct 2005, Larry Wall wrote: : > c| or C| maybe. [snip] : if $foo eq c|d { ... } Other suggestions welcome. <| maybe? And what will we make |> do? Michele -- Se non te ne frega nulla e lo consideri un motore usa e getta, vai pure di avviatore, ma e' un vero delitto. Un po' come vedere un cavallo che sodomizza un criceto!!! - Cesare/"edizioni modellismo sas" in it.hobby.modellismo
Y [was: "Re: new sigil"]
On Thu, 20 Oct 2005, Juerd wrote: All non-ASCII operators have ASCII equivalents: ¥ Y « << » >> Speaking of which the advantage of, say, « over << is that the former is _one_ charachter. But Y, compared to ¥, is one charachter only as well, and is even more visually distinctive with most fonts I know of, afaict, so is there any good reason to keep the latter as the "official" one?!? Michele -- Commander Helena Braddock: So, where is everybody? Melanie Ballard: Yeah, Friday night, the whole place should be packed. A whole twelve hours before sun up and there's money to burn, whores to fuck and drugs to take. - Gosts of Mars (2001)
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: new sigil
On Thu, Oct 20, 2005 at 08:55:46AM -0700, Larry Wall wrote: > On Thu, Oct 20, 2005 at 05:53:00PM +0200, Juerd wrote: > : Larry Wall skribis 2005-10-20 8:46 (-0700): > : > On Thu, Oct 20, 2005 at 05:35:10PM +0200, Juerd wrote: > : > : I'm sure ¢ will have its equivalent too. > : > c| or C| maybe. > : > : But > : > : sub c { ... } > : sub d { ... } > : > : if $foo eq c|d { ... } > > Other suggestions welcome. I don't know ... since we're still using ::T for classy things, I'd kind of like to see something with a : in it. I also get the feeling that these are type/class placeholders, so I wouldn't mind a ^ either. Here are some suggestions: :$T :^T ^^T :&T $::T $:T [T] # these next 3 don't evoke "variable" as much as # parametric type (ala C++) (T) And yes, I know several of those are already "taken". I'm suggesting that we at least think about reassigning them. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: new sigil
On 10/20/05, Juerd <[EMAIL PROTECTED]> wrote: > Schneelocke skribis 2005-10-20 18:00 (+0200): > > Would c! be an option? > > In current Perl 6: Yes, because infix ! does not exist. > > But several people want ! to be a chainy none() constructor, and this > would destroy a dream. You seem to be forgetting that we do have the longest token rule. So, the only way this destroys a dream (and likewise, the only way c| doesn't work), is if you have the poor package or class name c and you insist on writing c|d or c!d without spaces. Still, if you'd like to make a suggestion instead of just telling us why our ideas don't work in very specific circumstances, feel free. Luke
Re: new sigil
Schneelocke skribis 2005-10-20 18:00 (+0200): > Would c! be an option? In current Perl 6: Yes, because infix ! does not exist. But several people want ! to be a chainy none() constructor, and this would destroy a dream. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: new sigil
On 20/10/05, Larry Wall <[EMAIL PROTECTED]> wrote: > : But > : > : sub c { ... } > : sub d { ... } > : > : if $foo eq c|d { ... } > > Other suggestions welcome. Would c! be an option? -- schnee
Re: new sigil
On 10/20/05, Larry Wall <[EMAIL PROTECTED]> wrote: > Another thing I didn't mention is that that binds both the variable > and its class. But the $ variable is of course optional after the > type, so you could just write that > > sub sametype (¢T, ¢T) {...} > > if you don't actually care about $x and $y. Basically, ¢T captures > the type of the associated scalar in any lvalue or declarative context, > whether or not hte scalar itself is captured. So it's a type position thing if it can be. Good. (I wonder if, since it's allowed in term position, we will come up with ambiguities) How about this: sub foo(c|T $x) { my sub util (c|T $in) {...} util($x) } Is that c|T in util() a new, free type variable, or am I asserting that the type of util()'s argument must be the same type as $x? Luke
Re: new sigil
On Thu, Oct 20, 2005 at 05:53:00PM +0200, Juerd wrote: : Larry Wall skribis 2005-10-20 8:46 (-0700): : > On Thu, Oct 20, 2005 at 05:35:10PM +0200, Juerd wrote: : > : I'm sure ¢ will have its equivalent too. : > c| or C| maybe. : : But : : sub c { ... } : sub d { ... } : : if $foo eq c|d { ... } Other suggestions welcome. Larry
Re: new sigil
On Thu, Oct 20, 2005 at 07:56:09AM -0700, Larry Wall wrote: : I don't know how long this EuroOSCON net is going to stay up, so I'll be : brief. I think we're having a new "class" sigil. Where we've been : writing ::T, that will revert to meaning "an existing class T that : we just might not see the declaration of for dynamic reasons". Instead, : the new sigil is the cent sign, so ::T is now written ¢T instead. : : In addition, it doesn't automatically bind to T like we were making ::T : do, so you have to use it consistently: : : sub sametype (¢T $x, ¢T $y) {...} Another thing I didn't mention is that that binds both the variable and its class. But the $ variable is of course optional after the type, so you could just write that sub sametype (¢T, ¢T) {...} if you don't actually care about $x and $y. Basically, ¢T captures the type of the associated scalar in any lvalue or declarative context, whether or not hte scalar itself is captured. Sorry for all the short notes--we still don't know how long this OSCON net will be up before they take it down. Larry
Re: new sigil
Larry Wall skribis 2005-10-20 8:46 (-0700): > On Thu, Oct 20, 2005 at 05:35:10PM +0200, Juerd wrote: > : I'm sure ¢ will have its equivalent too. > c| or C| maybe. But sub c { ... } sub d { ... } if $foo eq c|d { ... } Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: new sigil
On Thu, Oct 20, 2005 at 11:46:30AM -0400, John Siracusa wrote: : On 10/20/05 11:37 AM, Larry Wall wrote: : > On Thu, Oct 20, 2005 at 10:32:14AM -0500, Steve Peters wrote: : > : The idea of punishing programmers who choose to use certain operating system : > : or locales just doesn't seem right to me. : > : > That's why we provide ugly ASCII workarounds for all of them. We just : > haven't decided what the appropriate ugly ASCII workaround for ¢ should be. : : So...no joy on the class(T) builtin/macro/whatever? Does it look too much : like a cast? It looks too much like a class declaration, and we're not declaring a class. We're just declaring a variable that holds something that "does class". Larry
Re: new sigil
On Thu, Oct 20, 2005 at 08:45:25AM -0700, Larry Wall wrote: : More info. ¢T is a scalar variable just like $T, but enforces a : class view, so you can use it as a class parameter, and pass any : object to it, but only access the classish aspects of the object. And a nice side effect of that is that declaring the invocant ¢T doesn't commit to whether you are thinking in a class-based or prototype-based model. And you wouldn't care until you got down to a .clone or a .bless. Larry
Re: new sigil
On Thu, Oct 20, 2005 at 05:35:10PM +0200, Juerd wrote: : I'm sure ¢ will have its equivalent too. c| or C| maybe. Larry
Re: new sigil
On 10/20/05 11:37 AM, Larry Wall wrote: > On Thu, Oct 20, 2005 at 10:32:14AM -0500, Steve Peters wrote: > : The idea of punishing programmers who choose to use certain operating system > : or locales just doesn't seem right to me. > > That's why we provide ugly ASCII workarounds for all of them. We just > haven't decided what the appropriate ugly ASCII workaround for ¢ should be. So...no joy on the class(T) builtin/macro/whatever? Does it look too much like a cast? -John
Re: new sigil
More info. ¢T is a scalar variable just like $T, but enforces a class view, so you can use it as a class parameter, and pass any object to it, but only access the classish aspects of the object. The only other big difference is that you can use it in the class syntactic slot, so it's legal to say ¢T $x where it would be illegal to say $T $x. Larry
Re: new sigil
On Thu, Oct 20, 2005 at 10:32:14AM -0500, Steve Peters wrote: : The idea of punishing programmers who choose to use certain operating system : or locales just doesn't seem right to me. That's why we provide ugly ASCII workarounds for all of them. We just haven't decided what the appropriate ugly ASCII workaround for ¢ should be. Larry
Re: new sigil
Steve Peters skribis 2005-10-20 10:32 (-0500): > The idea of punishing programmers who choose to use certain operating system > or locales just doesn't seem right to me. All non-ASCII operators have ASCII equivalents: ¥ Y « << » >> I'm sure ¢ will have its equivalent too. (It's ^KCt in vim, btw) Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: new sigil
On Thu, Oct 20, 2005 at 10:21:53AM -0500, Steve Peters wrote: : On Thu, Oct 20, 2005 at 07:56:09AM -0700, Larry Wall wrote: : > I don't know how long this EuroOSCON net is going to stay up, so I'll be : > brief. I think we're having a new "class" sigil. Where we've been : > writing ::T, that will revert to meaning "an existing class T that : > we just might not see the declaration of for dynamic reasons". Instead, : > the new sigil is the cent sign, so ::T is now written ¢T instead. : > : Looking at my U.S. English keyboard, I don't have a cent sign. I don't : think a sigil that can't be typed (or easily typed) is something that : should be used. Part of the reason for picking it is that we want to discourage people from using it unless they're experts. But it's in Latin-1, so it's not going to be any harder than the other Latin-1 characters we've used to type. Larry
Re: new sigil
On Thu, Oct 20, 2005 at 05:17:57PM +0200, Juerd wrote: > Juerd skribis 2005-10-20 17:03 (+0200): > > 4. Why not ^, which is available? > > Or the euro symbol, which also has a C in it. It doesn't always have to > be American ;) It's in iso-8859-15, which is compatible enough with > iso-8859-1 to support ¥ and both « and ». (I hope those turn out as Y, > << and >>'s pretty equivalents.) > I think that you can type the above characters on some systems, but others, like the one I'm using right now, I can't even copy and paste those characters in. I also know that on Windows, those characters may be available, but, for the typical user, these characters are annoyingly impossible to write. For example to type the yen symbol, its an ALT-0165 and requires the numeric keypad. The idea of punishing programmers who choose to use certain operating system or locales just doesn't seem right to me. Steve Peters [EMAIL PROTECTED]
Re: new sigil
On Thu, Oct 20, 2005 at 07:56:09AM -0700, Larry Wall wrote: > I don't know how long this EuroOSCON net is going to stay up, so I'll be > brief. I think we're having a new "class" sigil. Where we've been > writing ::T, that will revert to meaning "an existing class T that > we just might not see the declaration of for dynamic reasons". Instead, > the new sigil is the cent sign, so ::T is now written ¢T instead. > Looking at my U.S. English keyboard, I don't have a cent sign. I don't think a sigil that can't be typed (or easily typed) is something that should be used. Steve Peters [EMAIL PROTECTED]
Re: new sigil
Juerd skribis 2005-10-20 17:03 (+0200): > 4. Why not ^, which is available? Or the euro symbol, which also has a C in it. It doesn't always have to be American ;) It's in iso-8859-15, which is compatible enough with iso-8859-1 to support ¥ and both « and ». (I hope those turn out as Y, << and >>'s pretty equivalents.) Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: new sigil
Juerd skribis 2005-10-20 17:03 (+0200): > 3. What is the ASCII equivalent? Suggestion: 1c 'c' is an invalid character in numbers, and currently only numbers can begin with a digit. 1cFoo The 1 provides an extra visual hint of the cheapness of the class. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: new sigil
Larry Wall skribis 2005-10-20 7:56 (-0700): > the new sigil is the cent sign, so ::T is now written ¢T instead. 1. What does it look like? I've never used a cent sign, and have seen several. 2. How can it be typed with X character composition, vim's digraphs and major international keyboards? 3. What is the ASCII equivalent? 4. Why not ^, which is available? 5. Why is the sigil needed? Pairs do well without, too. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: new sigil
On 10/20/05 10:56 AM, Larry Wall wrote: > I don't know how long this EuroOSCON net is going to stay up, so I'll be > brief. I think we're having a new "class" sigil. Where we've been > writing ::T, that will revert to meaning "an existing class T that > we just might not see the declaration of for dynamic reasons". Instead, > the new sigil is the cent sign, so ::T is now written ¢T instead. How about an ASCII version and/or a class() built-in that means the same thing? ¢T == class(T) == ?T ^ | Dunno what to put there -John
new sigil
I don't know how long this EuroOSCON net is going to stay up, so I'll be brief. I think we're having a new "class" sigil. Where we've been writing ::T, that will revert to meaning "an existing class T that we just might not see the declaration of for dynamic reasons". Instead, the new sigil is the cent sign, so ::T is now written ¢T instead. In addition, it doesn't automatically bind to T like we were making ::T do, so you have to use it consistently: sub sametype (¢T $x, ¢T $y) {...} Within a larger scope, you can always alias, though: ::T := ¢T; 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
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