Re: Apo2: \Q ambiguity
On Fri, May 04, 2001 at 06:29:21PM +0100, Richard Proctor wrote: > In Apocalypse 2, \Q is being used for two things, and I believe this > may be ambiguious. Probably Larry was thinking \E (end of special treatment), originally. -- Raul
Re: Apo2: \Q ambiguity
Larry Wall <[EMAIL PROTECTED]> writes: >Dan Sugalski writes: >: Have you considered allowing Unicode characters as alternatives to some of >: the less pleasant looking bits? $foo<<1>> (where << and >> are the double >: angle characters) as an alternative to $foo\Q[1] if the user's got the >: characters handy? > >Actually, my first thought a year or three ago was to replace qw() >with «», but we just aren't there with the Unicode editors yet. >My keyboard seems to be missing a few of the characters, too. :-) MultiKey < < is what it takes «here». But I don't see why AltGr < should not work (SuSE Linux's keymap is so un-mnemonic compared to Sun's compose key scheme). -- Nick Ing-Simmons who is looking for a new job see http://www.ni-s.u-net.com/
Re: Apo2: \Q ambiguity is too a problem
Larry Wall wrote: > > The ~~ is a cute hack though. Credit is due to Steve Lane <[EMAIL PROTECTED]> who posted it to funwithperl. ... > I'm sorry, my eyes go crossed when I look at that, and the two \Q's > merge into one, which confuses me, in a stereoscopic sort of way. I was wrong about \Q\E anyway. Apparently it gets optimized out of the doublequoting process _BEFORE_ the interpolation occurs, so it cannot break up the expression. Which is very odd since it happens _after_ interpolation normally since it affects interpoincluded parts of the string. metaquoting must happen multiple times in the course of the p5 interplation process. And \E\Q fails to have the first \E knock the metaquote count into the negatives. \q is free however so why not use define \q as the zero-length noninterpolable expression, instead of tossing out the nifty if rarely used snap-on socket that is the metaquoting sequence? > We could leave \Q{} as metaquote and use \E for a expression stopper, > though that would be confusing to people used to the old \E, which is > dead, dead, dead, drive a stake through its heart, dead. (I hope...) > > Larry \Q{} seems like an alien in a land populated with qw, qh, qr, etc. Why not join the parade and use qm, if abandoning \Q...\E? print SCRIPT "touch $(qm($filename))";
Re: Apo2: \Q ambiguity
Johan Vromans wrote: > > [Quoting Michael G Schwern, on May 6 2001, 22:58, in "Re: Apo2: \Q ambigui"] > > Hmmm, maybe you can point out the "compose" key on my keyboard, I > > can't find it. ;) > > Pick whatever you find convenient. I use the right control key. > From my .Xmodmap: > > ! Compose key > keycode 109 = Multi_key > > > I know what Larry went through. I had to do quite a bit of work just > > to be able to type a £ symbol. I wound up remapping my 'option' key > > (that's 'alt' to you non-Mac people) to £. since we appear to be sharing on this topic, I ran perl -e 'for (32..255){print chr};print $/' and then used mouse paste, when I wanted « and ». ¢£¤¥¦§¨©ª«¬®¯°±²³´µ¶·¸¹º»¼½¾¿ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐ ÑÒÓÔÕÖ×ØÙÚÛÜÝÞßàáâãäåæçèéêëìíîïðñòóôõö÷øùúûüýþÿ are all in there somewhere.
Re: Apo2: \Q ambiguity
[Quoting Michael G Schwern, on May 6 2001, 22:58, in "Re: Apo2: \Q ambigui"] > Hmmm, maybe you can point out the "compose" key on my keyboard, I > can't find it. ;) Pick whatever you find convenient. I use the right control key. From my .Xmodmap: ! Compose key keycode 109 = Multi_key > I know what Larry went through. I had to do quite a bit of work just > to be able to type a £ symbol. I wound up remapping my 'option' key > (that's 'alt' to you non-Mac people) to £. Compose L - for me. > I still haven't managed to get my xterms to display it right and had > to switch from my normal "Clean" font in emacs because it doesn't > support high ascii to "Neep". My favourite font is -dec-terminal-medium-r-normal--14-140-75-75-c-80-iso8859-1 but -misc-fixed-medium-r-normal--10-*-75-75-*-*-iso8859-1 will do as well. Note that these support ISO-8859-1. > Stupid American Computers aren't quite ready for the Unicode invasion. And this is only just Latin-1... Back to Perl6! -- Johan
Re: Apo2: \Q ambiguity
On Sun, May 06, 2001 at 10:23:18PM +0200, Johan Vromans wrote: > Larry Wall <[EMAIL PROTECTED]> writes: > > I won't tell you what I had to go through just to get those two > > characters into this message, and they're still only in Latin-1. > > Compose < < and an average version of X. Hmmm, maybe you can point out the "compose" key on my keyboard, I can't find it. ;) I know what Larry went through. I had to do quite a bit of work just to be able to type a £ symbol. I wound up remapping my 'option' key (that's 'alt' to you non-Mac people) to £. I still haven't managed to get my xterms to display it right and had to switch from my normal "Clean" font in emacs because it doesn't support high ascii to "Neep". Stupid American Computers aren't quite ready for the Unicode invasion. -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One Free beer w/riot!
Re: Apo2: \Q ambiguity
Larry Wall <[EMAIL PROTECTED]> writes: > Actually, my first thought a year or three ago was to replace qw() > with «», but we just aren't there with the Unicode editors yet. IIRW, German uses «» but French uses »« ... > I won't tell you what I had to go through just to get those two > characters into this message, and they're still only in Latin-1. Compose < < and an average version of X. -- Johan
Re: Apo2: \Q ambiguity
At 06:40 PM 5/4/2001 -0700, Larry Wall wrote: >Dan Sugalski writes: >: That's cool. I was just thinking it might not be a bad idea for us to >: set some equivalencies up in advance. If not, that's fine too. (I'll just >: slip them in while you're not looking... :) > >Hmm. Harks back to the colonial era: "I claim these brackets in the >name of Perl." Hmm. I guess the "We came in peace for all mankind" >approach only works when you're quite sure nobody else is gonna claim >it for themselves any time soon, which is much truer of the Moon than >of Unicode. We hope. I expect that's true, though in the context of the perl 6 parser it's not a huge deal--just because someone else claims it doesn't mean much, as it'll be claimed in a different parser module. Seems reasonable to make some claims for perl, though. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Apo2: \Q ambiguity
Dan Sugalski writes: : That's cool. I was just thinking it might not be a bad idea for us to set=20 : some equivalencies up in advance. If not, that's fine too. (I'll just slip= : =20 : them in while you're not looking... :) Hmm. Harks back to the colonial era: "I claim these brackets in the name of Perl." Hmm. I guess the "We came in peace for all mankind" approach only works when you're quite sure nobody else is gonna claim it for themselves any time soon, which is much truer of the Moon than of Unicode. We hope. Larry
Re: Apo2: \Q ambiguity not a problem
David L. Nicol writes: : Not a problem. \Q means quotemeta, except immediately following : a interpolated identifier. You want to start metaquoting immediately : after a curious interpolation? use \Q\Q. The word "except" should be a red flag that you're trying to define an exception. We're trying to reduce the number of exceptions these days, at least in the areas where context sensitivity doesn't buy you power. : I have been regularly, since I fingured out how, doing things like : : : print "the time is now ${\(~~localtime)}[go home!]"; # double-not : "scalar" golf hack Er, if you've been doing things like that, then you must be fond of syntax errors. Those are not "weird brackets", they're just dereference brackets. Perl 5 keeps parsing the expression after ${}, so [go home!] is a subscript. The ~~ is a cute hack though. Weird brackets are only of the form ${foo[bar]} or ${foo{bar}}. We're not proposing to get rid of ${foo}[bar], except insofar as we're making it do the same thing inside quotes as outside, which it doesn't right now. : in p6 without "weird brackets" I supposed this becomes : : print "the time is now $(+localtime)\Q[go home!]"; I think $() will end interpolation automatically (since you could always put the subscript inside if you really want it), so the \Q wouldn't be necessary. And you don't want + there unless you want it numified, I suspect, though I could change my mind on that. The $() already puts it in scalar context. : Right? So if I wanted to quotemeta this thing so I could let sh have it : safely, what in apo2 is preventing me from writing : : print "the time is\Q now < $(+localtime)\Q[go home!] \E"; : : the only time there's an ambiguity is when the metaquoting starts : immediately : after the stopped variable identifier I'm sorry, my eyes go crossed when I look at that, and the two \Q's merge into one, which confuses me, in a stereoscopic sort of way. : print SH "echo the time is now `date` so go $destinations{first}\Q\Q : <$tainted> \E"; : perl -le'print "\Q\Q\Q <<\E<\E< \E <"' : \\\ \\\<\\\<\\\<\<\ < : : metaquote stacks -- why not use \E instead? it has the same issues, but : has : no effect at all currently, and E is for End_of_interpolble_specifier a lot : more than \Q does. : : \Q\E is a safe zero-length noninterpolable in any context however, with : no side effect We could leave \Q{} as metaquote and use \E for a expression stopper, though that would be confusing to people used to the old \E, which is dead, dead, dead, drive a stake through its heart, dead. (I hope...) Larry
Re: Apo2: \Q ambiguity
At 03:51 PM 5/4/2001 -0700, Larry Wall wrote: >Dan Sugalski writes: >: Have you considered allowing Unicode characters as alternatives to some of >: the less pleasant looking bits? $foo<<1>> (where << and >> are the double >: angle characters) as an alternative to $foo\Q[1] if the user's got the >: characters handy? > >Actually, my first thought a year or three ago was to replace qw() >with «», but we just aren't there with the Unicode editors yet. >My keyboard seems to be missing a few of the characters, too. :-) > >I won't tell you what I had to go through just to get those two >characters into this message, and they're still only in Latin-1. > >So my take is that people should be able to define their operators up >into the Unicode range if that makes them happy, and they don't plan to >ship their code widely in the next year or two. That's cool. I was just thinking it might not be a bad idea for us to set some equivalencies up in advance. If not, that's fine too. (I'll just slip them in while you're not looking... :) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Apo2: \Q ambiguity not a problem
Not a problem. \Q means quotemeta, except immediately following a interpolated identifier. You want to start metaquoting immediately after a curious interpolation? use \Q\Q. I have been regularly, since I fingured out how, doing things like print "the time is now ${\(~~localtime)}[go home!]"; # double-not "scalar" golf hack in p6 without "weird brackets" I supposed this becomes print "the time is now $(+localtime)\Q[go home!]"; Right? So if I wanted to quotemeta this thing so I could let sh have it safely, what in apo2 is preventing me from writing print "the time is\Q now < $(+localtime)\Q[go home!] \E"; the only time there's an ambiguity is when the metaquoting starts immediately after the stopped variable identifier print SH "echo the time is now `date` so go $destinations{first}\Q\Q <$tainted> \E"; perl -le'print "\Q\Q\Q <<\E<\E< \E <"' \\\ \\\<\\\<\\\<\<\ < metaquote stacks -- why not use \E instead? it has the same issues, but has no effect at all currently, and E is for End_of_interpolble_specifier a lot more than \Q does. \Q\E is a safe zero-length noninterpolable in any context however, with no side effect Garrett Goebel wrote: > > From: Larry Wall [mailto:[EMAIL PROTECTED]] > > Richard Proctor writes: > > : In Apocalypse 2, \Q is being used for two things, and I > > : believe this may be ambiguious. > > : > > : It has the current \Quote meaning admitibly \Q{oute} it is > > : also being proposed for a null token disambiguate context. > > : As in $foo\Q[bar]. > > > > Hmm, yes, that's a problem. I'd forgotten about the quotemeta kludge. > > I'll have to think about it. Maybe quotemeta becomes \qm{} > > or some such. > > The problem with \Q quotemeta was the biggest thing to jump out at me when > reading A2... That is before my brain turned to mush. Seems like quotemeta > be serving its purpose if you have to consider escaping its contents... > What's the Perl6 equivalent to: > > #!perl -w > # script.pl: > my ($match, $filename) = @ARGV; > local $/; > open FH, $filename; > $file = ; > print scalar @{[$file =~ m/(\Q$match\E)/gs]}; > 1; > __END__ > > file.txt contents: > {foo}\E{foo}\E{foo} > > > script.pl {foo} file.txt > 3 > > -- David Nicol 816.235.1187 [EMAIL PROTECTED] Parse, munge, repeat.
Re: Apo2: \Q ambiguity
Dan Sugalski writes: : Have you considered allowing Unicode characters as alternatives to some of : the less pleasant looking bits? $foo<<1>> (where << and >> are the double : angle characters) as an alternative to $foo\Q[1] if the user's got the : characters handy? Actually, my first thought a year or three ago was to replace qw() with «», but we just aren't there with the Unicode editors yet. My keyboard seems to be missing a few of the characters, too. :-) I won't tell you what I had to go through just to get those two characters into this message, and they're still only in Latin-1. So my take is that people should be able to define their operators up into the Unicode range if that makes them happy, and they don't plan to ship their code widely in the next year or two. After that, once most of the artificial cross-cultural barriers are torn down, we'll be left with the real cross-cultural barriers, which will be a little harder to get over. Americans will be slow in picking up Kanji, I suspect. But the APL operators are foreign to just about everyone, so that handicaps us all equally. By the way, $¾ is not valid Perl, comments on Slashdot notwithstanding. Variables still have to start with a letter (or ideograph). It might well be the case that ¾ could be defined to return 0.75, however. Larry
Re: Apo2: \Q ambiguity
At 10:11 PM 5/4/2001 +0100, Simon Cozens wrote: >On Fri, May 04, 2001 at 03:05:12PM -0400, Dan Sugalski wrote: > > Have you considered allowing Unicode characters as alternatives to some of > > the less pleasant looking bits? $foo<<1>> (where << and >> are the double > > angle characters) as an alternative to $foo\Q[1] if the user's got the > > characters handy? > >I superficially like this idea, but then when the file gets passed to a >user who doesn't have the relevant Unicode support you get >$foo1, which isn't fun to support any >more. As opposed to "my $" as someone decides to use Katakana variable names? :) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Apo2: \Q ambiguity
At 11:33 PM 5/4/2001 +0200, Bart Lateur wrote: >On Fri, 04 May 2001 15:05:12 -0400, Dan Sugalski wrote: > > >Have you considered allowing Unicode characters as alternatives to some of > >the less pleasant looking bits? $foo<<1>> (where << and >> are the double > >angle characters) as an alternative to $foo\Q[1] if the user's got the > >characters handy? > >Until now, all characters with a special meaning for the syntax of the >language, are in the ASCII range. I see no reason to change that. This >is the case for most programming languages, with as a notable exception >APL. Yes, I know. I'm not asking that we have syntax characters that are exclusively Unicode, merely that some of the skankier bits have neater Unicode equivalents. If we're not going to allow Unicode identifiers then I withdraw the suggestion. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Apo2: \Q ambiguity
On Fri, 04 May 2001 15:05:12 -0400, Dan Sugalski wrote: >Have you considered allowing Unicode characters as alternatives to some of >the less pleasant looking bits? $foo<<1>> (where << and >> are the double >angle characters) as an alternative to $foo\Q[1] if the user's got the >characters handy? Until now, all characters with a special meaning for the syntax of the language, are in the ASCII range. I see no reason to change that. This is the case for most programming languages, with as a notable exception APL. -- Bart.
Re: Apo2: \Q ambiguity
On Fri, May 04, 2001 at 03:05:12PM -0400, Dan Sugalski wrote: > Have you considered allowing Unicode characters as alternatives to some of > the less pleasant looking bits? $foo<<1>> (where << and >> are the double > angle characters) as an alternative to $foo\Q[1] if the user's got the > characters handy? I superficially like this idea, but then when the file gets passed to a user who doesn't have the relevant Unicode support you get $foo1, which isn't fun to support any more. -- DISCLAIMER: Use of this advanced computing technology does not imply an endorsement of Western industrial civilization.
Re: Apo2: \Q ambiguity
At 11:10 AM 5/4/2001 -0700, Larry Wall wrote: >Larry Wall writes: >: Richard Proctor writes: >: : In Apocalypse 2, \Q is being used for two things, and I believe this >may be >: : ambiguious. >: : >: : It has the current \Quote meaning admitibly \Q{oute} it is also being >: : proposed for a null token disambiguate context. As in $foo\Q[bar]. >: >: Hmm, yes, that's a problem. I'd forgotten about the quotemeta kludge. >: I'll have to think about it. Maybe quotemeta becomes \qm{} or some such. > >I guess that might also mean that \L turns into \ql{} and \U turns into >\qu{}. Hmm. That would mean that > > $x = ql{$(EXPR)}; > >means the same thing as lc(EXPR). Interesting. Have you considered allowing Unicode characters as alternatives to some of the less pleasant looking bits? $foo<<1>> (where << and >> are the double angle characters) as an alternative to $foo\Q[1] if the user's got the characters handy? Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Apo2: \Q ambiguity
From: Larry Wall [mailto:[EMAIL PROTECTED]] > Richard Proctor writes: > : In Apocalypse 2, \Q is being used for two things, and I > : believe this may be ambiguious. > : > : It has the current \Quote meaning admitibly \Q{oute} it is > : also being proposed for a null token disambiguate context. > : As in $foo\Q[bar]. > > Hmm, yes, that's a problem. I'd forgotten about the quotemeta kludge. > I'll have to think about it. Maybe quotemeta becomes \qm{} > or some such. The problem with \Q quotemeta was the biggest thing to jump out at me when reading A2... That is before my brain turned to mush. Seems like quotemeta be serving its purpose if you have to consider escaping its contents... What's the Perl6 equivalent to: #!perl -w # script.pl: my ($match, $filename) = @ARGV; local $/; open FH, $filename; $file = ; print scalar @{[$file =~ m/(\Q$match\E)/gs]}; 1; __END__ file.txt contents: {foo}\E{foo}\E{foo} > script.pl {foo} file.txt 3 >
Re: Apo2: \Q ambiguity
Larry Wall writes: : Richard Proctor writes: : : In Apocalypse 2, \Q is being used for two things, and I believe this may be : : ambiguious. : : : : It has the current \Quote meaning admitibly \Q{oute} it is also being : : proposed for a null token disambiguate context. As in $foo\Q[bar]. : : Hmm, yes, that's a problem. I'd forgotten about the quotemeta kludge. : I'll have to think about it. Maybe quotemeta becomes \qm{} or some such. I guess that might also mean that \L turns into \ql{} and \U turns into \qu{}. Hmm. That would mean that $x = ql{$(EXPR)}; means the same thing as lc(EXPR). Interesting. Don't panic, I'm just thinking out loud... Larry
Re: Apo2: \Q ambiguity
Richard Proctor writes: : In Apocalypse 2, \Q is being used for two things, and I believe this may be : ambiguious. : : It has the current \Quote meaning admitibly \Q{oute} it is also being : proposed for a null token disambiguate context. As in $foo\Q[bar]. Hmm, yes, that's a problem. I'd forgotten about the quotemeta kludge. I'll have to think about it. Maybe quotemeta becomes \qm{} or some such. Larry