Re: C style conditional statements
Le Wed, May 12, 2004 at 02:00:42AM +0200, le valeureux mongueur Pedro Larroy a dit:
> Hi
>
> Is there any chance that in perl6 there will be the possibility to write
> if/else statements without {}s with the condition at the beginning?
>
> Like
>
> if (condition)
> statement;
>
> In order not to break traditional C culture. Is there any technical
> reason why it wasn't done in perl5?
In Perl5, variable declaration are an executable statement. Also the
scope of a variable starts from its declaration and ends at the
end of the immediately enclosing block. Things would get
problematic if the branches of an if/else were not scoped.
What would be the meaning of :
if (condition)
my $foo = 'bar';
else
print $foo;
Now about the syntax, it is not clear if the statement before
the 'else' can/must be semicolon terminated.
A similar example of stange meshing of scope and flow of control in
perl5 is:
my $foo = $bar if $buz;
I can't even remember what it supposed to do when it is in a loop
where $bar and $buz change. And I would bet that the exact
semantic is not even documented in most books.
--
stef
>
> Regards.
>
> --
> Pedro Larroy Tovar | Linux & Network consultant | piotr%member.fsf.org
>
> Software patents are a threat to innovation in Europe please check:
> http://www.eurolinux.org/
Re: C style conditional statements
Stéphane Payrard wrote:
Le Wed, May 12, 2004 at 02:00:42AM +0200, le valeureux mongueur Pedro Larroy a dit:
Hi
Is there any chance that in perl6 there will be the possibility to write
if/else statements without {}s with the condition at the beginning?
Like
if (condition)
statement;
In order not to break traditional C culture. Is there any technical
reason why it wasn't done in perl5?
In Perl5, variable declaration are an executable statement. Also the
scope of a variable starts from its declaration and ends at the
end of the immediately enclosing block. Things would get
problematic if the branches of an if/else were not scoped.
What would be the meaning of :
if (condition)
my $foo = 'bar';
else
print $foo;
Not entirely sure, but according to the camel book, another reason for
the braces being compulsory is that Perl makes a distinction between a
block and a statement, whereas in C a block is actually (sometimes) a
kind of statement - indeed a compound statement. Of course, it's
possible that was just an excuse, but it does make a fair bit of sense.
Especially since Perl's got things like anonymous subroutines and
closures, which are sort of fancy blocks, and ultimately one has to
realise that { and } don't mean the same thing in Perl at all. They just
*look* like they do.
I am actually glad to see Perl 6 extending this trend, as it seems to be
using { and } for Good Things. I wouldn't argue at all that it's
important to keep familiarity for C programmers anymore (so sayeth the
Haskell programmer), although it might perhaps be a little early to go
for Python-like syntax. For some reason, lots of people don't like it
when indentation is what's controlling their code structure...
Re: C style conditional statements
On Wed, May 12, 2004 at 12:57:15AM -0400, Andrew Rodland wrote:
> On Tuesday 11 May 2004 10:13 pm, Larry Wall wrote:
> > On Tue, May 11, 2004 at 08:31:55PM -0400, Andrew Rodland wrote:
> > : On Tuesday 11 May 2004 08:00 pm, Pedro Larroy wrote:
> > : > Hi
> > : >
> > : > Is there any chance that in perl6 there will be the possibility to
> > : > write if/else statements without {}s with the condition at the
> > : > beginning?
>
> > : Yes, I know that I'm diverting rather than strictly answering. My
> > : personal opinion is that I can live with it, because I've shot myself in
> > : that particular foot before, and that there are good reasons. My other
> > : opinion is that I wouldn't mind if a particular rule in the grammar could
> > : be enabled / disabled with "use strict 'braces'" either, as it is
> > : somewhat unperlish to prevent footshooting for that sake alone.
> >
> > That's gonna be pretty unlikely. We've basically decided that, in
> > terms of readability, it makes a whole lot more sense to get rid of
> > the parens than the curlies, and you can't make both the parens and
> > the curlies optional.
> >
>
> Aha. I knew that there was one important point that I was missing out on, and
> that's the one. And that one does count as a "technical" reason for p6, if
> not p5. Hope I've clarified, Pedro.
>
> --Andrew
Yes, thanks a lot for your answers. I appreciate them.
I think I'm now pretty attached to perl culture and I'm just a little worried,
as a humble perl programmer, about "things changing too much" in perl6.
Specially after reading coments like getting rid of the parens and go for
a "python syntax".
Since I'm started to read perl RFC's and apocalypses now, I don't know very
well if those design decissions are already closed now.
Is there any document (asides from the ones I mentioned) that would give
"the big picture" to the average perl programmer about what perl6 will be?
Kind regards.
--
Pedro Larroy Tovar | Linux & Network consultant | piotr%member.fsf.org
Software patents are a threat to innovation in Europe please check:
http://www.eurolinux.org/
Re: C style conditional statements
Pedro Larroy writes: > Yes, thanks a lot for your answers. I appreciate them. > > I think I'm now pretty attached to perl culture and I'm just a little > worried, as a humble perl programmer, about "things changing too much" > in perl6. Specially after reading coments like getting rid of the > parens and go for a "python syntax". You musn't be afraid. Perl 6 is different from Perl 5 in many ways, but rest assured it is still Perl. The philosophy is still there; the natural feel is still there; the incomprehensible flexibility is still there; the sigils, paren-less functions, semicolon separators, golfability -- all the things you love -- not going anywhere. A good portion of the documentation effort has been dedicated to explaining to the community that Perl 6 isn't new and scary, but new and familiar. You'll find this in the earlier Exegeses, Piers Cawley's article "Perl 6: Not Just for Damians" (http://www.perl.com/pub/a/2001/10/23/damians.html), some of the presentations from the last few conference seasons, and scattered about the community. > Since I'm started to read perl RFC's and apocalypses now, I don't know very > well if those design decissions are already closed now. There's really only one design decision that is "closed", and that's that we're going to use Parrot. Though you might consider things that you'll never convince Larry to do in a million years "closed". But really, if there's something that you've read and you don't like about the language, and you have a good reason, bring it up here and we'll talk about it. Who knows, you might even make a difference. :-) > Is there any document (asides from the ones I mentioned) that would give > "the big picture" to the average perl programmer about what perl6 will be? Those documents at dev.perl.org/perl6 are the best we've got. The Exegeses and Synopses will give you a better idea than the Apocalypses will, but they are all talking about the things that are changin', rather than the things that are, if I may quote Nancy Sinatra, samin'. Luke
Re: C style conditional statements
[EMAIL PROTECTED] (Luke Palmer) writes: > familiar. You'll find this in the earlier Exegeses, Piers Cawley's > article "Perl 6: Not Just for Damians" > (http://www.perl.com/pub/a/2001/10/23/damians.html), some of the > presentations from the last few conference seasons, and scattered about > the community. These things are all convincing examples of how friendly and familiar Perl 6 was three years ago. -- "The best index to a person's character is a) how he treats people who can't do him any good and b) how he treats people who can't fight back." -- Abigail Van Buren
Re: C style conditional statements
On Wed, May 12, 2004 at 09:47:04AM +0100, Matthew Walton wrote: : For some reason, lots of people don't like it when indentation is : what's controlling their code structure... Indentation is a wonderful form of commentary from programmer to programmer, but its symbology is largely wasted on the computer. We don't tell poets how to format their poetry. Larry
Re: C style conditional statements
On Wed, May 12, 2004 at 09:47:04AM +0100, Matthew Walton wrote: : although it might perhaps be a little early to go for Python-like syntax. s/early/late/ Python's syntax succeeds in combining the mistakes of Lisp and Fortran. I do not contrue that as progress. Larry
Re: C style conditional statements
On Wed, 2004-05-12 at 11:22, Simon Cozens wrote:
> [EMAIL PROTECTED] (Luke Palmer) writes:
> > familiar. You'll find this in the earlier Exegeses, Piers Cawley's
> > article "Perl 6: Not Just for Damians"
> > (http://www.perl.com/pub/a/2001/10/23/damians.html), some of the
> > presentations from the last few conference seasons, and scattered about
> > the community.
>
> These things are all convincing examples of how friendly and familiar
> Perl 6 was three years ago.
Right off the bat, let me say that I've read A1-6, E7, A12, S3, S6, E1,
E6 and much of this mailing list, but I'm still not sure that all of
what I'm going to say is right. Please correct me if it's not.
Perl 5:
#!/usr/bin/perl
while(<>) {
s/\w+/WORD/g;
print;
}
Perl 6:
#!/usr/bin/perl
while $stdin.getline -> $_ {
s:g/\w+/WORD/;
$stdout.print;
}
is it really that new and scary? The wonky old STDIO is probably going
to go and get replaced with an IO::Handle like interface (I don't think
that's final, but I recall it being said), but that's NOT new, it's just
changing over to the long-established and removing the Perl3ish IO
syntax.
The options go on the beginning of the regexp. Ok, fine. No big deal.
The funky -> syntax replaces implicit $_ization of while parameters...
good change IMHO.
. replaces -> for invoking/dereferencing. Again, a good visual change,
and no real hardship to get used to unless string-. has just broken your
brain forever. Using ~ instead of _ for concatenation was a recent break
from the A1-3 ideas, and I'm glad of it. _ was a poor choice due to
variable naming rules, forcing a bit too much whitespace dwimery.
Other than that it's Perl as you've always known it. Any Perl 5
programmer should be able to look it over and figure it out with perhaps
just one or two hints.
Ok, another:
#!/usr/bin/perl
use IO::Socket::INET;
$n=IO::Socket::INET->new(LocalPort=>20010,Listen=>5);
$n->listen();
while(($s=$n->accept())){
print <$s>;
close $s;
}
Perl 6:
#!/usr/bin/perl
use IO::Socket::INET;
my IO::Socket::INET $n = (LocalPort=>20010,Listen=>5);
$n.listen();
while ($s=$n.accept()) {
$stdout.print($s.getlines);
$s.close;
}
Again, not much difference. STDIO is still the biggest visual change.
Page after page after page of A12, and still this code looks the same.
I'd say that's a win!
Ok, now I admit that:
package Foo;
require Exporter;
our @ISA=qw(Exporter);
sub new {
my $class = shift;
return bless [EMAIL PROTECTED], $class;
}
sub bark {
my $self = shift;
return $self->{bark};
}
looks quite a bit different from:
class Foo {
has $.bark;
}
But really... which would you prefer?! Will code break? Sure (well, not
counting compatibility mode, which is a very good idea), but I'm happy
to move forward with the language after years of essentially static
mucking about with Perl 5. Yeah, "our" is new. Yeah, threads have become
usable. But overall, the language still suffers from most of the things
that were "ok enough to release Perl 5" more than 10 years ago... it's
time.
If anything though, over the last 2 years, more and more Perl 5 culture
has re-asserted itself over the design on Perl 6.
--
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback
Re: C style conditional statements
Aaron Sherman skribis 2004-05-12 14:04 (-0400):
> Perl 5:
> #!/usr/bin/perl
> while(<>) {
> s/\w+/WORD/g;
> print;
> }
> Perl 6:
> #!/usr/bin/perl
> while $stdin.getline -> $_ {
Empty <> uses ARGV, not STDIN. It only uses STDIN if not @ARGV (or if
'-' is in @ARGV).
> s:g/\w+/WORD/;
> $stdout.print;
A2 says $*STDIN and $*STDOUT. Has this been changed?
Also, will there no longer be the concept of a selected filehandle? I'd
hate to have to specify stdin and stdout in throw away scripts.
> }
I think I like this better:
for <> {
s:g/\w+/WORD/;
print;
}
But I think I still want to have some non-mutating version of s/// that
returns the modified string, so that you can just write something like
print s:gx/\w+/WORD/ for <>;
Juerd
$foo.s/foo/bar/
Juerd skribis 2004-05-12 20:15 (+0200): > But I think I still want to have some non-mutating version of s/// that > returns the modified string, so that you can just write something like > print s:gx/\w+/WORD/ for <>; Actually, can't we just use the . for s///? You'd then use $foo.s/// to get the new string ang $foo.=s/// to mutate $foo. For bare s///, I think copying is more useful than mutating. I'm not sure, and am posting this before actually thinking about it :) Juerd
Re: C style conditional statements
Larry Wall wrote: On Wed, May 12, 2004 at 09:47:04AM +0100, Matthew Walton wrote: : For some reason, lots of people don't like it when indentation is : what's controlling their code structure... Indentation is a wonderful form of commentary from programmer to programmer, but its symbology is largely wasted on the computer. We don't tell poets how to format their poetry. When you put it like that, I'm almost converted. My favourite language that does indentation as syntax is Haskell - where it's optional, so I'm not really all that passionate about it. I just don't mind it.
Re: C style conditional statements
On Wed, May 12, 2004 at 08:15:36PM +0200, Juerd wrote:
: A2 says $*STDIN and $*STDOUT. Has this been changed?
It's $*IN and $*OUT.
: Also, will there no longer be the concept of a selected filehandle?
That is correct.
: I'd hate to have to specify stdin and stdout in throw away scripts.
Just because there's no longer a selected filehandle doesn't mean
you have to specify stdout. It's still the default. It's just no
longer the default default. Translated Perl 5 scripts that select
the current output filehandle will need to use an explicit variable
to hold the "default". The translator will also need to translate
idioms like
select((select(FOO),$| = 1)[0]);
to something like:
$FOO.autoflush = 1;
: I think I like this better:
:
: for <> {
: s:g/\w+/WORD/;
: print;
: }
That will work fine in Perl 6. It won't even chew up all your memory
as it would in Perl 5.
Larry
Re: C style conditional statements
Aaron Sherman writes:
> Right off the bat, let me say that I've read A1-6, E7, A12, S3, S6, E1,
> E6 and much of this mailing list, but I'm still not sure that all of
> what I'm going to say is right. Please correct me if it's not.
Did you really need to ask me to? ;-)
> Perl 5:
>
> #!/usr/bin/perl
>
> while(<>) {
> s/\w+/WORD/g;
> print;
> }
>
> Perl 6:
>
> #!/usr/bin/perl
>
> while $stdin.getline -> $_ {
> s:g/\w+/WORD/;
> $stdout.print;
> }
It actually turns into:
for <> {
s:g/\w+/WORD/;
print;
}
Which looks and feels even more like Perl (and not like Java...). I'll
explain below.
> is it really that new and scary? The wonky old STDIO is probably going
> to go and get replaced with an IO::Handle like interface (I don't think
> that's final, but I recall it being said), but that's NOT new, it's just
> changing over to the long-established and removing the Perl3ish IO
> syntax.
Well, the IO-objects are iterators, and you use <$iter> to iterate. It
makes sense that <> would iterate over $*ARGV by default.
> The funky -> syntax replaces implicit $_ization of while parameters...
> good change IMHO.
It doesn't *replace* it. Actually, $_ becomes even more pervasive. In
a closure block like:
for @something -> $foo { ... }
BOTH $foo and $_ get bound to each element of @something. That just
means that $_ is always the current inner topic, as opposed to only when
you have another name for it.
> Other than that it's Perl as you've always known it. Any Perl 5
> programmer should be able to look it over and figure it out with perhaps
> just one or two hints.
>
> Ok, another:
>
> #!/usr/bin/perl
>
> use IO::Socket::INET;
> $n=IO::Socket::INET->new(LocalPort=>20010,Listen=>5);
> $n->listen();
> while(($s=$n->accept())){
> print <$s>;
> close $s;
> }
>
>
> Perl 6:
>
> #!/usr/bin/perl
>
> use IO::Socket::INET;
> my IO::Socket::INET $n = (LocalPort=>20010,Listen=>5);
> $n.listen();
> while ($s=$n.accept()) {
> $stdout.print($s.getlines);
> $s.close;
> }
Here you go:
use IO::Socket::INET;
my $n = new IO::Socket::INET: LocalPort => 20010, Listen => 5;
$n.listen();
while (my $s = $n.accept) {
print <$s>;
$s.close; # or even close $s;
}
The second line has a lot of different variants; I opted on the side of
conservatism.
Luke
Re: C style conditional statements
Larry Wall skribis 2004-05-12 11:39 (-0700):
> On Wed, May 12, 2004 at 08:15:36PM +0200, Juerd wrote:
> : A2 says $*STDIN and $*STDOUT. Has this been changed?
> It's $*IN and $*OUT.
I like this change!
> : I'd hate to have to specify stdin and stdout in throw away scripts.
> Just because there's no longer a selected filehandle doesn't mean
> you have to specify stdout. It's still the default. It's just no
> longer the default default. Translated Perl 5 scripts that select
> the current output filehandle will need to use an explicit variable
> to hold the "default".
Some tools like Irssi and my own PLP tie a handle and then select it, to
intercept the output of normal print statements. But STDOUT can still be
specified explicitly if that's where you want things to go.
This makes the tools compatible with most code out there, for easy
copying and pasting. (Think of it what you want, but this is and will
stay the way beginners create their programs.)
If there is just a default, but no way of changing it, you'd have to tie
$*OUT itself. But how would one then reach the real stdout, in case it's
needed?
I hope I'm missing something :)
> : for <> {
> : s:g/\w+/WORD/;
> : print;
> : }
> That will work fine in Perl 6. It won't even chew up all your memory
> as it would in Perl 5.
The lazy readline list is one of the things that make me love Perl 6. I
didn't even think about this snippet in Perl 5 context.
Juerd
Re: C style conditional statements
Luke Palmer skribis 2004-05-12 12:46 (-0600): > Well, the IO-objects are iterators, and you use <$iter> to iterate. It > makes sense that <> would iterate over $*ARGV by default. $*ARGS? > my $n = new IO::Socket::INET: LocalPort => 20010, Listen => 5; I'd like to be able[1] to write my $n = new IO::Socket::INET :LocalPort 20010 :Listen 5; But unfortunately, parens are not optional with :pairs. Juerd [1] Because I'd use something like that in other contexts. I expect that I will not use indirect object syntax even in Perl 6 and will in reality write: my $n = IO::Socket::INET.new LocalPort => 20010, Listen => 5;
Re: C style conditional statements
On Wed, May 12, 2004 at 08:48:07PM +0200, Juerd wrote: : Some tools like Irssi and my own PLP tie a handle and then select it, to : intercept the output of normal print statements. But STDOUT can still be : specified explicitly if that's where you want things to go. : : This makes the tools compatible with most code out there, for easy : copying and pasting. (Think of it what you want, but this is and will : stay the way beginners create their programs.) : : If there is just a default, but no way of changing it, you'd have to tie : $*OUT itself. But how would one then reach the real stdout, in case it's : needed? : : I hope I'm missing something :) Well, yes, you're missing the fact that $*OUT is a variable in Perl 6: $*SAVED = $*OUT; local($*OUT) = fake_handle(); So you might consider that $*OUT is Perl 6's equivalent to the currently selected output filehandle. Note however that, like select(), the above does not redirect stdout for subprocesses. It only redirects methods implicitly bound to $*OUT, like C. Larry
signature of a program
"Luke Palmer" <[EMAIL PROTECTED]> wrote
> Well, the IO-objects are iterators, and you use <$iter> to iterate. It
> makes sense that <> would iterate over $*ARGV by default.
When I read this, I instinctively thought to myself: "why does this need to
be global?". And that thought progressed to: "what is the signature of a
main program?"
When you start a perl program, you don't need a "main" function, but the
program is a lexical scope from which you return. its just the "sub"
declaration that is implicit:
sub main::_([EMAIL PROTECTED]) returns int {...}
or some such thing. Is this really the best signature we could use? Given
that we want a ref to the array to be the default topic, perhaps the
signature is:
class main is program {
has @.ARGV is rw;
has %.ENV is rw;
method _() returns int { ... }
}
We could then paste any number of program attributes into that class: %.ENV,
$.STDIN, $.STDOUT, etc. Thing like $*IN would just be aliases to those
attributes: @*ARGV := .ARGV; etc.
If I stretch my imagination a little, I could even see user-code creating
other instances of program you use in place of functions like system and
exec.
sub qw(Str $exe) { program.new( $exe ) as string }
OK, maybe that's not quite what you'd want, but I you get the picture (I
hope).
Dave.
Re: $foo.s/foo/bar/
On Wed, 2004-05-12 at 14:22, Juerd wrote:
> Actually, can't we just use the . for s///?
Well, that brings up something that I don't think Larry has covered yet.
That is, it brings into question what s/// *is* in the grammar.
Is it a special type of calling convention, e.g.:
sub s (Regex $pat, Str $replace, bool ?$i) is doublequotelike returns(Str) {
bool $did = false;
if my $match = ($CALLER::_ =~ m:i($i)/$pat/) {
$match = $replace;
$did = true;
}
return $did;
}
or is it something more deeply buried in the parser? If it's just
quoting, then that's (relatively) easy:
class String {
...
method s (...) is doublequotelike ... {...}
}
Otherwise, you would have to bury this deep in the parser as a special
case with the definition of s/// and that seems of questionable value
for the complexity you add.
--
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback
Yadda yadda yadda some more
I like C<...>
I like it a LOT.
In fact, I'm partial to the idea that it should be usable anywhere:
class {
has $.a;
has $.b;
...;
}
or
my Foo $a = ...; # Ask Bob what this should be -Bill
In all cases, I'm a fan of C<...> being valid syntax, but returning a
run-time exception. It's just a lovely bit of code-as-documentation.
--
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback
Re: Yadda yadda yadda some more
Aaron Sherman skribis 2004-05-12 17:30 (-0400): > I like C<...> I like it a LOT. In fact, I'm partial to the idea that > it should be usable anywhere I agree. It'd make even more of my pseudo code (#perlhelp and perlmonks.org) valid syntax :). Juerd
Re: C style conditional statements
Juerd wrote: my $n = IO::Socket::INET.new LocalPort => 20010, Listen => 5; Or, if I'm remembering correctly: my IO::Socket::INET $n .= new LocalPort => 20010, Listen => 5; I really hope I'm remembering correctly. Is this turning into the 'look how great Perl 6 is' thread?
Re: C style conditional statements
Matthew Walton writes: > Juerd wrote: > > >my $n = IO::Socket::INET.new LocalPort => 20010, Listen => 5; > > Or, if I'm remembering correctly: > > my IO::Socket::INET $n .= new LocalPort => 20010, Listen => 5; > > I really hope I'm remembering correctly. Is this turning into the 'look > how great Perl 6 is' thread? Yep, you are. And yep, it is. We've needed one of those. Luke
Re: $foo.s/foo/bar/
Aaron Sherman writes:
> On Wed, 2004-05-12 at 14:22, Juerd wrote:
>
> > Actually, can't we just use the . for s///?
>
> Well, that brings up something that I don't think Larry has covered yet.
> That is, it brings into question what s/// *is* in the grammar.
Well, I imagine it's just a macro called C that turns itself into an
appropritate sub call.
As a method, I don't think it exists. It's more of a $str.subst(). You
can't add special parse rules to methods, since you can't do polymorphic
parsing[1]. So you'd more likely have:
my $subd = $str.subst(
rx/ \w+ / => "WORD",
);
Which would open up:
my $subd = $str.subst(
rx/ I\< (.*?) \> / => { "$1" },
rx/ \< / => '<',
rx/ \> / => '>',
);
à la Regexp::Subst::Parallel. Provided the hypothetical scoping works
out there. Hmm, would the scope of $1 propagate?
Luke
[1] I feel a new experimental language coming on... >:-}
Re: C style conditional statements
[EMAIL PROTECTED] (Aaron Sherman) writes:
> is it really that new and scary?
No, but not for the reasons you think. You seem to believe that you're
comparing Perl and a Perl-derived language and pointing out that they're
both like Perl, but it looks like you're comparing two Algol-derived
languages and pointing out that they both look like Algol.
By declaring any change between the two code examples to be "good" in your
subjective opinion you mentally absolve any difference in "Perlness",
which means that you don't actually address the issue at all:
> Ok, fine. No big deal.
> good change IMHO.
> Again, a good visual change,
Aye, but changes they are!
> Ok, another:
> #!/usr/bin/perl
> use IO::Socket::INET;
> $n=IO::Socket::INET->new(LocalPort=>20010,Listen=>5);
> $n->listen();
> while(($s=$n->accept())){
> print <$s>;
> close $s;
> }
require 'IO/Socket/INET';
$n = IO::Socket::INET.new({ :LocalPort => 20010, :Listen => 5 });
$n.listen();
while ($s=$n.accept())
print $s.gets;
$s.close;
end
Again, not much difference. "end" to delimit a block is probably the biggest
visual difference. : to qualify barewords as symbols, but hey, that seems like
a positive change to me. Page after page after page of A12, and still this
code looks the same. I'd say that's a win!
But, you know, somehow I suspect exactly the same arguments will magically
not apply to other languages, right?
> But really... which would you prefer?!
That wasn't the question. Of course I prefer Perl 6. I prefer it because it
isn't Perl, though, not because it is!
--
even though I know what a 'one time pad' is, it still sounds like
a feminine hygiene product.
Re: Yadda yadda yadda some more
On Wed, May 12, 2004 at 11:37:44PM +0200, Juerd wrote: : Aaron Sherman skribis 2004-05-12 17:30 (-0400): : > I like C<...> I like it a LOT. In fact, I'm partial to the idea that : > it should be usable anywhere : : I agree. It'd make even more of my pseudo code (#perlhelp and : perlmonks.org) valid syntax :). Er. Why are you guys using the subjunctive? Larry
Re: $foo.s/foo/bar/
Juerd wrote: Juerd skribis 2004-05-12 20:15 (+0200): But I think I still want to have some non-mutating version of s/// that returns the modified string, so that you can just write something like print s:gx/\w+/WORD/ for <>; Actually, can't we just use the . for s///? You'd then use $foo.s/// to get the new string ang $foo.=s/// to mutate $foo. Working from the other direction, parens are not valid pattern delimiters, leaving s() open for use: print s(/:g \w+/, 'WORD'); (Or somesuch...dunno about the positioning of :g.) -- Brent "Dax" Royal-Gordon <[EMAIL PROTECTED]> Perl and Parrot hacker Oceania has always been at war with Eastasia.
