Re: Light ideas
Ah! Ok, yes, I had missed that. Thanks, this is exactly what I wanted. Dave On Mon, 5 Aug 2002, Stephen Rawls wrote: > >> Doesn't the :w option do that? > >> :w/one two/ translates to /one \s+ two/ > > >Not exactly. The regex you showed would match any of these (using > underscores for > >spaces for clarity): > >"one_two", "one__two", "one__two" > > Ah, ok. This is from Synopsis 5, this should be what you want: > > A leading ' indicates an interpolated literal match (including whitespace): > / <'match this exactly (whitespace matters)'> / > > cheers, > Stephen Rawls > >
Re: Light ideas
From: "Damian Conway" <[EMAIL PROTECTED]> > > what would "true" (the string) be converted to? > > In a numeric context: 0 (as in Perl 5). which was my point. You wouldn't want to cast any ol' scalar as a number just to get 1 or 0 representations or TRUE or FALSE... that wouldn't DWIM. -Miko
Re: Light ideas
--- Dave Storrs <[EMAIL PROTECTED]> wrote: > Actually, this is one thing that has troubled me > about the new regex rules, and I've mentioned it > before. I would still like for there to be > a "reverse /x" switch, that would tell the > regex that I want it to treat whitespace > literally Doesn't the :w option do that? :w/one two/ translates to /one \s+ two/ cheers, Stephen Rawls __ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com
Re: Light ideas
Uri Guttman wrote: > but remember that whitespace is ignored as the /x mode is on > all the time. Whoops, yeah. For some reason I kept literal mode on when reading the spaces between two literals. The rules {foo bar} and {foobar} are the same, but some very low level part of my brain is resisting that. I have no trouble with {foo | bar} and {foo|bar} though. Is this a standard issue defect or should I complain to my parents? - Ken
Re: Light ideas
> "KF" == Ken Fox <[EMAIL PROTECTED]> writes: > Dave Storrs wrote: >> why didn't you have to write: >> >> rule ugly_c_comment { >> / >> \/ \* [ .*? ? ]*? \* \/ >> { let $0 := " " } >> / >> } > Think of the curly braces as the regex quotes. If "{" is the quote > then there's nothing special about "/" and it doesn't need to be > escaped. Also, I don't think you want spaces between "/" and "*" > because "/ *" isn't a comment delimiter. but remember that whitespace is ignored as the /x mode is on all the time. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com - Stem and Perl Development, Systems Architecture, Design and Coding Search or Offer Perl Jobs http://jobs.perl.org
Re: Light ideas
On Sat, 3 Aug 2002, Ken Fox wrote: > Dave Storrs wrote: > > why didn't you have to write: > > > >rule ugly_c_comment { > > > / > > > \/ \* [ .*? ? ]*? \* \/ > > > { let $0 := " " } > > > / > >} > > Think of the curly braces as the regex quotes. If "{" is the quote > then there's nothing special about "/" and it doesn't need to be > escaped. Ok, good. Then it *does* work the way I thought. Thanks. >Also, I don't think you want spaces between "/" and "*" > because "/ *" isn't a comment delimiter. True, but as I understand it, literal whitespace in a regex is no longer significant...so writing "/ *" in a regex is equivalent to writing "/*" or "/*" etc. In order to match an actual "/ *", you would need to write "/\s+*". Actually, this is one thing that has troubled me about the new regex rules, and I've mentioned it before. I would still like for there to be a "reverse /x" switch, that would tell the regex that I want it to treat whitespace literally...if for no other reason than because it would reduces line noise in regexen. In most situations you probably wouldn't want it, but I can think of occasions when you would. Dave Storrs
Re: Light ideas
Dave Storrs wrote: > why didn't you have to write: > > rule ugly_c_comment { > / > \/ \* [ .*? ? ]*? \* \/ > { let $0 := " " } > / > } Think of the curly braces as the regex quotes. If "{" is the quote then there's nothing special about "/" and it doesn't need to be escaped. Also, I don't think you want spaces between "/" and "*" because "/ *" isn't a comment delimiter. > 2) As written, I believe that the ugly_c_comment rule would permit nested > comments (that is, /* /**/ */), but would break if the comments were > improperly nested (e.g., /* /* */). Is that correct? It wouldn't fail, but it would scan to EOF and then back track. Basically the inner succeeds and then the rest of the file is scanned for <'*/'>. When that fails, the regex back tracks to the inner , fails that and then skips the unbalanced "/*" with .*?. I'd like to add ::: to fail the entire comment if the inner comment fails, but I'm not sure how to do it. Does this work? /\* [ .*? | ::: ]*? \*/ > 3) The rule will replace the comment with a single, literal space. Why is > this replacement necessary...isn't it sufficient to simply define it as > whitespace, as was done above? Probably. I think it's a hold-over from thinking of parser vs lexer, but that may not be true depending on how the rest of the grammar uses white space. IMHO value bound to the white space production should be the actual text (the comment in this case). - Ken
Re: Light ideas
On Sat, 3 Aug 2002, Damian Conway wrote: > > don't know exactly what the syntax for adding /* */ will be > > Something like this: > > grammar Perl::With::Ugly::C::Comments is Perl { > > rule ws { | } > > rule ugly_c_comment { > /\* [ .*? ? ]*? \*/ > { let $0 := " " } > } > } > > caller{MY}.parser(Perl::With::Ugly::C::Comments); I'm still having trouble getting my head around the new grammar-construction rules. Three questions: 1) Am I right that anything inside a "rule" block is considered to be inside a regex? If not, why didn't you have to write: rule ugly_c_comment { / \/ \* [ .*? ? ]*? \* \/ { let $0 := " " } / } 2) As written, I believe that the ugly_c_comment rule would permit nested comments (that is, /* /**/ */), but would break if the comments were improperly nested (e.g., /* /* */). Is that correct? 3) The rule will replace the comment with a single, literal space. Why is this replacement necessary...isn't it sufficient to simply define it as whitespace, as was done above? Dave Storrs
Re: Light ideas
Miko O'Sullivan wrote: > OK, would that notation ( @arr[] = $var ) be something that could be added > by a module, in the same way that operators and /* */ will be addable? I > don't know exactly what the syntax for adding /* */ will be Something like this: grammar Perl::With::Ugly::C::Comments is Perl { rule ws { | } rule ugly_c_comment { /\* [ .*? ? ]*? \*/ { let $0 := " " } } } caller{MY}.parser(Perl::With::Ugly::C::Comments); > but if you can > say to the preprocessor something like s#/*#=comment#g then perhaps you can > also say something like s#\[\s*\]\s*=#binpush#g and then also define binpush > as an operator. You could rebuild the lexical parser grammar as above (to allow the lamentable C<@arr[] = $scalar> syntax), or you could just create a new operator with something like: module BinaryPush; my sub operator:<-- is exported (@array is rw, $scalar) { push @array, $scalar; } # and elsewhere... use BinaryPush; @arr <-- $val; Damian
Re: Light ideas
At 8:53 AM -0400 8/2/02, Trey Harris wrote: >(With the possible exception of modules that disobey the laws of physics, >but I'm not putting anything past Larry... no strict 'physics' ;) Yeek! Hopefully Larry'll forbear--while he may be able to pull that one off, I'm afraid I'm not up to the task... :) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Light ideas
On Fri, 2 Aug 2002, Nicholas Clark wrote: : On Fri, Aug 02, 2002 at 08:53:51AM -0400, Trey Harris wrote: : > (With the possible exception of modules that disobey the laws of physics, : > but I'm not putting anything past Larry... no strict 'physics' ;) : : Yay! : : $ cat infinite_compression.pl : #!/usr/local/bin/perl6 : use strict; # Hopefully this triggers the p5 to p6 convertor. : use warnings; : no strict 'physics'; : use Compress::SnakeOil; : : while my $infile (@ARGV) { : my $outfile = "$infile.inf"; : compress_file (infile => $infile, outfile => $outfile, level => "Infinite"); : die "Problem compressing $infile to $outfile" unless -z $outfile; : } : __END__ : : : I do hope that works. :-) Infinite compression works great. Unfortunately, it's lossy. And done right, it requires infinite time. Larry
Re: Light ideas
On Fri, Aug 02, 2002 at 08:53:51AM -0400, Trey Harris wrote: > You've often asked this list, "will doing X in a module be possible?" > Consider the things that Damian's already done with modules in Perl 5. I > think Damian's involvement in Perl 6 if nothing else will insure that, no > matter what X stands for, the answer will be "yes." :-) > > Trey > > (With the possible exception of modules that disobey the laws of physics, > but I'm not putting anything past Larry... no strict 'physics' ;) Yay! $ cat infinite_compression.pl #!/usr/local/bin/perl6 use strict; # Hopefully this triggers the p5 to p6 convertor. use warnings; no strict 'physics'; use Compress::SnakeOil; while my $infile (@ARGV) { my $outfile = "$infile.inf"; compress_file (infile => $infile, outfile => $outfile, level => "Infinite"); die "Problem compressing $infile to $outfile" unless -z $outfile; } __END__ I do hope that works. :-) Nicholas Clark
Re: Light ideas
In a message dated Fri, 2 Aug 2002, Miko O'Sullivan writes: > OK, would that notation ( @arr[] = $var ) be something that could be added > by a module, in the same way that operators and /* */ will be addable? I don't think we've seen too much about how Larry plans to do Perl-munging-Perl except that we know it will be much more easily possible, and it will be based upon the grammars we saw in A5. That said, you could add this syntax fairly easily in Perl 5 with source filters (well, as easily as source filters ever are). I'd be highly surprised if that ability went away in Perl 6. You've often asked this list, "will doing X in a module be possible?" Consider the things that Damian's already done with modules in Perl 5. I think Damian's involvement in Perl 6 if nothing else will insure that, no matter what X stands for, the answer will be "yes." :-) Trey (With the possible exception of modules that disobey the laws of physics, but I'm not putting anything past Larry... no strict 'physics' ;)
Re: Light ideas
> > - There's already a huge population of programmers out there who already use > > this notation. I frankly admit that I think of PHP as a great idea that > > wasn't done quite right. > > I agree. Including that notation! ;-) Touche. Darn it's difficult disagreeing with pithy people. :-) OK, would that notation ( @arr[] = $var ) be something that could be added by a module, in the same way that operators and /* */ will be addable? I don't know exactly what the syntax for adding /* */ will be, but if you can say to the preprocessor something like s#/*#=comment#g then perhaps you can also say something like s#\[\s*\]\s*=#binpush#g and then also define binpush as an operator. -Miko
Re: Light ideas
Miko O'Sullivan aksed: > what would "true" (the string) be converted to? In a numeric context: 0 (as in Perl 5). > Here's my point more > explicitly: in a boolean context, there's no need to get any specific string > (0, 1, "yup") as long as it correctly expresses true or false. It's when > you convert a boolean into a string or number that it becomes convenient to > define how they are represented by default. Yes, of course there are already > ways to change a variable from [some representation of false] to 0, but by > giving a slick way to default the string, a lot of ?? :: type stuff can be > done away with. Well, given that Perl 6 has an actual BOOL subtype, maybe C and C could return objects with: * a Boolean conversion to 1/"" * a string conversion to "true"/"false" * a numeric conversion to 1/0 > That sounds like a great way to do it. A follow up question, then: would it > be easy enough to accomplish that in a use-type format? I.e., something > like I said earlier: > > use StrictBoolean TRUE=>1, FALSE=>0; > > or even just let it default: > > use StrictBoolean; Yes. In Perl 6 C statements will, by default be lexical in effect. The module itself *might* look like this: module StrictBoolean; my @truth = ({TRUE=>1, FALSE=>0}); sub import ($class, *%beauty) { push @truth, \%beauty } sub unimport { pop @truth } sub true is exported { return @truth[-1]{TRUE} } sub false is exported { return @truth[-1]{FALSE} } > The issue of what is more intuitive is of course highly subjective, but I > would argue that for several reasons the more concise version is more > unituitive to the population at large: Quite possibly. This is why I was so subjunctive about that option. And why I'm happy to leave such decisions to Larry. His track-record on DWIMity is exceptional. :-) > - There's already a huge population of programmers out there who already use > this notation. I frankly admit that I think of PHP as a great idea that > wasn't done quite right. I agree. Including that notation! ;-) Damian
Re: Light ideas
From: "Dave Mitchell" <[EMAIL PROTECTED]> > But perl5 already does this: Dave gets the "First to Point Out the Feature Exists" award. I knew that out of three ideas I'd be lucky if just one of them was actually a new feature idea. I might still say that the parens don't make things quite obvious... what if I need to use parens for a complex regex but *don't* want the delimiters? But I'm not sure that it's worth changing if it already exists in some form. From: "Damian Conway" <[EMAIL PROTECTED]> [talking about the boolean representation thing] > Though I must say I can't see the real need for this. Especially when > you can prefix any boolean expression with unary + and ensure that > any ""s are converted to 0's anyway. what would "true" (the string) be converted to? Here's my point more explicitly: in a boolean context, there's no need to get any specific string (0, 1, "yup") as long as it correctly expresses true or false. It's when you convert a boolean into a string or number that it becomes convenient to define how they are represented by default. Yes, of course there are already ways to change a variable from [some representation of false] to 0, but by giving a slick way to default the string, a lot of ?? :: type stuff can be done away with. > { > temp sub false() {0} > # etc. > } That sounds like a great way to do it. A follow up question, then: would it be easy enough to accomplish that in a use-type format? I.e., something like I said earlier: use StrictBoolean TRUE=>1, FALSE=>0; or even just let it default: use StrictBoolean; > > @arr[] = $var; > > > I have to admit that don't find that syntax very intuitive. > Besides, in Perl 5 the same functionality just: > > $arr[@arr] = $var; > > In Perl 6, that would be: > > @arr[+@arr] = $var; > > or: > > @arr[@arr.length] = $var; > > or maybe just : > > @arr[.length] = $var; The issue of what is more intuitive is of course highly subjective, but I would argue that for several reasons the more concise version is more unituitive to the population at large: - Generally, shorter is better as long as it isn't ambiguous (maybe it is ambigous, what do you think?) - It doesn't get bogged down in what the stuff in the braces means - Those +s and ?s and _s are going to take some getting used to. People will probably learn this little shortcut faster than they learn the new casting symbols. - There's already a huge population of programmers out there who already use this notation. I frankly admit that I think of PHP as a great idea that wasn't done quite right. I'd love to see the PHPers of the world migrate to Perl. Oh, and sorry about the subject line in the previous email... my cut-n-pasting was off target. -Miko