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
--- 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
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 wrote:
why didn't you have to write:
rule ugly_c_comment {
/
\/ \* [ .*? 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 ugly_c_comment succeeds and then the rest
of the file is scanned for '*/'. When that fails, the regex
back tracks to the inner ugly_c_comment, 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?
/\* [ .*? | ugly_c_comment ::: ]*? \*/
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
KF == Ken Fox [EMAIL PROTECTED] writes:
Dave Storrs wrote:
why didn't you have to write:
rule ugly_c_comment {
/
\/ \* [ .*? 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
- 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
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
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
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
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
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 { Perl::ws | ugly_c_comment }
rule ugly_c_comment {
/\* [ .*? 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
Carr[] = $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
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 { Perl::ws | ugly_c_comment }
rule ugly_c_comment {
/\* [ .*? 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 {
/
\/ \* [ .*? 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
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
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 Ctrue and Cfalse
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 Cuse 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
