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
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
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: 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!
--
dhd even though I know what a 'one time pad' is, it still sounds like
a feminine hygiene product.
C style conditional statements
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?
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
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?
Like
if (condition)
statement;
In order not to break traditional C culture. Is there any technical
reason why it wasn't done in perl5?
My understanding is that it was mostly a /(counter)?cultural/ decision, to
make dangling-else syndrome impossible. For the same reason else if is
spelled elsif, so there doesn't have to be a special braceless exception
for else.
It might also be wise to note that if your statement is really that simple and
important, you might be better off writing statement if condition.
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.
Cheers,
Andrew
Re: C style conditional statements
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?
:
: Like
:
: if (condition)
: statement;
:
: In order not to break traditional C culture. Is there any technical
: reason why it wasn't done in perl5?
:
: My understanding is that it was mostly a /(counter)?cultural/ decision, to
: make dangling-else syndrome impossible. For the same reason else if is
: spelled elsif, so there doesn't have to be a special braceless exception
: for else.
:
: It might also be wise to note that if your statement is really that simple and
: important, you might be better off writing statement if condition.
:
: 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.
Perl 1 had to maintain a lot of compatibility with C for general
acceptance (the bracketing rule being a glaring exception to that).
We think that nowadays we can edge away from some of the less useful
C heritage, as long as we stay close enough to our Perl heritage.
(Some would say we've already blown it there... :-)
Larry
Re: C style conditional statements
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
