Re: Shortcut: ?=
--- Miko O'Sullivan [EMAIL PROTECTED] wrote: SUMMARY C$var ?= $x : $y as a shortcut for C$var = $var ? $x : $y. DETAILS We have ||=, +=, -=, etc. These shortcuts (I'm sure there's some fancy linguistic term for them) save us a few keystrokes and clean up the code. So, concerning C? :, I find myself doing this type of thing a lot: $var = $var ? 1 : 0; The only time this doesn't change type (arguably a bad thing in its own right) is when you're doing boolean ops. And for those, there exist boolean operators. How 'bout a shortcut for that, something like this: $var ?= 1 : 0; Isn't this the same as C$var = 1; ? =Austin
Re: Shortcut: ?=
On Mon, Feb 03, 2003 at 06:25:09AM -0800, Austin Hastings wrote: The only time this doesn't change type (arguably a bad thing in its own right) is when you're doing boolean ops. And for those, there exist boolean operators. Changing type is a very Perlish thing to do. How 'bout a shortcut for that, something like this: $var ?= 1 : 0; Isn't this the same as C$var = 1; ? No for example, maps to 0. A better example: $var ??= 'succeeded' :: 'failed'; -- You're so sadly neglected, and often ignored. A poor second to Belgium, When going abroad. Monty Python - Finland
Re: Shortcut: ?=
On Mon, 3 Feb 2003, Deborah Ariel Pickett wrote: I guess what I'm saying is that someone needs to provide a real-world, non-contrived, example showing ??= in use. Fair enough. Real World, Non-Contrived: In all databases that I've ever worked with there are exactly two possible values for a boolean database field. Those two values are usually 't' and 'f', though in my designs I prefer to use '1' and '0', to keep things more perlish. Now, when a value comes in from a web page, it might be anything. In particular a checkbox is going to be either undef (if the checkbox wasn't checked, the standard is that the field isn't sent at all) or whatever the INPUT tag's VALUE attribute is set to, or 'on' (if VALUE isn't set). There is simply no way to directly get 'f' or 0 from the HTTP request, and 't' requires extra work. Ergo, it's necessary to massage the data a little to fit it into 't' and 'f'. In short, although Perl is quite robust about what's true and false, other computer systems are more fussy. I personally find myself explicitly setting variables to 1 or 0 quite frequently, and I always use ?:. It would be a nice little shorthand addition to have ??= in Perl6. Obviously this isn't a major requirement. It's just a nice little shortcut that would clean the code in the same way the other shortcuts do. I always feel somehow redundant type C$var = $var ? 1 : 0, and ??= would just be nice and tidy. -miko Miko O'Sullivan Programmer Analyst Rescue Mission of Roanoke
Re: Shortcut: ?=
On Mon, 3 Feb 2003, Dave Mitchell wrote: $var ??= 'succeeded' :: 'failed'; Aha! $var 'succeeded' || 'failed'; Thank you, precedence. /s
Re: Shortcut: ?=
Argh. Please disregard that last message as the ramblings of a pre-caffeinated mind. /s On Mon, 3 Feb 2003, Sean O'Rourke wrote: On Mon, 3 Feb 2003, Dave Mitchell wrote: $var ??= 'succeeded' :: 'failed'; Aha! $var 'succeeded' || 'failed'; Thank you, precedence. /s
Re: Sabbatical from the list
Damian wrote: This is just to let everybody know that I will be unsubscribing from p6-lang for the foreseeable future, effective immediately. I deeply regret that I simply no longer have the time to cope with the volume of messages being generated here. Unfortunately, the exigencies of finding paying work in this woeful economic climate, and the demands of actually moving ahead with the design and implementation of Perl 6 must take priority. I will, of course, still read Piers' excellent summaries, but otherwise I won't be monitoring the list at all from here on. It is likely that I will start reading again after A6 and E6 are released. I've deputized Luke Palmer as a design team proxy. He'll be keeping an eye on the list and sending us good ideas. A huge number of features have been added and improved here on this list. We don't want to lose that input. We just have to change the information flow to cope with changing circustances. We're having another round of face-to-face design meetings this week, so you can expect some interesting bits to come out over the next month. Thanks go to everybody. We couldn't do this without you. Allison
Language Discussion Summaries
SUMMARY Members of the Perl6 Language list produce summaries discussions of proposed features of the Perl6 language. These summaries will improve the signal to noise ratio for Larry and his lieutenants as they try to keep up with feelings in the list. See http://www.idocs.com/perl6/ for the first example of a summary. DETAILS With Damian taking a break from the list, I've become concerned that ideas generated in this list will become buried in the volume of messages. If Larry, Damian, and other members of the core team have to read through every bottomless thread just to find out the ideas and opinions of the list members, they may never be able to keep up. Therefore, I propose that members of the language list provide summaries of the discussions in the group. Each summary describes a proposed idea feature of the language, then summarizes the list's feelings on the idea. Different opinions will be presented. The summaries will also attempt to provide a feeling for the weight of opinion, e.g., most people felt this way, some people felt differently, etc. The summaries will also link to the original threads so that readers can peruse the raw data. Although these summaries will be necessarily subjective, the authors will attempt to be journalistically objective. The authors will be clearly identified. If the authors participated in the thread, that fact will also be identified. Finally, anybody on the list who chooses may add a note that they concur with the summary (sorta like in science journals where authors are simply people who agree). Dissenting opinions (i.e. people who think the summary is innaccurate) might also be presented, but I'd rather just incorporate those opinions into the summary and reach a consensus that the summary correctly summarizes the thread. See http://www.idocs.com/perl6/ for the home page for the summaries and one example summary. -miko Miko O'Sullivan Programmer Analyst Rescue Mission of Roanoke
AW: Language Discussion Summaries
Thats a great idea. Murat
Re: Shortcut: ?=
I guess what I'm saying is that someone needs to provide a real-world, non-contrived, example showing ??= in use. Fair enough. Real World, Non-Contrived: In all databases that I've ever worked with there are exactly two possible values for a boolean database field. Those two values are usually 't' and 'f', though in my designs I prefer to use '1' and '0', to keep things more perlish. Now, when a value comes in from a web page, it might be anything. In particular a checkbox is going to be either undef (if the checkbox wasn't checked, the standard is that the field isn't sent at all) or whatever the INPUT tag's VALUE attribute is set to, or 'on' (if VALUE isn't set). There is simply no way to directly get 'f' or 0 from the HTTP request, and 't' requires extra work. Ergo, it's necessary to massage the data a little to fit it into 't' and 'f'. In short, although Perl is quite robust about what's true and false, other computer systems are more fussy. I personally find myself explicitly setting variables to 1 or 0 quite frequently, and I always use ?:. It would be a nice little shorthand addition to have ??= in Perl6. All right, I'm prepared to buy that argument. (Though I probably still wouldn't ever use the operator personally.) I presume you'll summarize this thread to the new area you announced today, since it seems that there aren't any strong objections. You should address these issues too, just to make it complete: - operator precedence and associativity - issues with typed variables - how it works with aggregates like arrays and hashes - whether there's a penguin^H^H^H^H^H^H^Hguillemo^Het hyper-op version of this, and how it looks (e.g., is the :: also bracketed?) and works. - context Some of these could be palmed off by saying The same as ?? ::, but we may as well be complete. -- Debbie Pickett http://www.csse.monash.edu.au/~debbiep [EMAIL PROTECTED] You gotta bat your eyes - like this. - _The Little Mermaid_
newline as statement terminator
In the tradition of Perl concision, I would like newline to be a
statement terminator everywhere it can: that is when
a) the parser expects an operator
_and_ b) we are not in the middle of a parenthesised expression.
Accessorily, it would also help people to switch back and forth
between language that use newline as statement terminator and perl6:
they will not be burn anymore when forgetting a semicolon.
Semicolons are still allowed everywhere as statement terminator
because empty statements are.
So, In the common case, oneliner atomic statements, the proposed rule
means: you can drop the ending semicolon.
BTW: Atomic statement are statement composed of one expression only.
For composite multiline statements, see About the b) rule below.
Multiline atomic statements just have to be broken at the right
place to avoid to break them:
a +
b
is equivalent to
a + b
But
a
+ b
are two statements.
Note that in Perl5, semicolon is not always required as statement
terminator. At the end of a scope, being a closing brace, or the end
of a program, including an explicit eval or an implicit one (perldb
shell).
Note that, for Perl 6, Larry has already opened the path in his fourth apocalypse:
$x = do {
...
} + 1;
is different from
$x = do {
...
}
+ 1;
I just want to make a rule of what Larry made a special case.
About the b) rule.
--
The following code does not parse because of the newlines that are
interpreted as statement terminator.
for
1..10
{ ... }
But
for (
1.. 10
) {
}
is legit.
Smart parser may allow to avoid these otherwise spurious parentheses
.. and make
for
1..10
{ ... }
a legit expression following the rule what could have a meaning should.
The b) rule may not even be necessary with enough parsing state.
The parser could have the following exclusive states:
1) expecting an operator
2) expecting an operand (newline is statement terminator)
The expected operand is an expression that is part of an atomic statement
deemed as atomic.
3) expecting an operand (newline is ignored)
The expected operand is an expression that is directly part of
a composite statement. (as opposed as part of an atomic
statement part of a composite one).
What I mean by deemed as atomic?
When parsing a composite statement, we don't know from the start that
it is so. The following statement:
$a if $b
is deemed atomic until the parse deals with the 'if' token.
My proposition could then be expressed informally:
Newline is interpred as statement terminator when it makes sense.
It does not when :
A) in the middle of an expression when an operand is expected
B) within a parenthesised expression
C) and other cases that would also cause the parsing to return an error
Note: The b/ rule was an undeeded attempt to force C/ into B/.
--
stef
Re: newline as statement terminator
Date: Tue, 4 Feb 2003 01:57:00 +0100
From: =?iso-8859-1?Q?St=E9phane?= Payrard [EMAIL PROTECTED]
In the tradition of Perl concision, I would like newline to be a
statement terminator everywhere it can: that is when
a) the parser expects an operator
_and_ b) we are not in the middle of a parenthesised expression.
Can you say Ruby?
No, I think a semicolon should still be required to seperate
statements.
Accessorily, it would also help people to switch back and forth
between language that use newline as statement terminator and perl6:
they will not be burn anymore when forgetting a semicolon.
Of course, error detection as far as semicolons go is getting much
better. Parsers can determine (usually) exactly which line the
semicolon was left off of.
Note that in Perl5, semicolon is not always required as statement
terminator. At the end of a scope, being a closing brace, or the end
of a program, including an explicit eval or an implicit one (perldb
shell).
That's because, in Perl 5, semicolon is not a statement terminator.
It is a statement Iseparator. That is why you don't need it at the
end of various places, because you don't need to separate it from
anything.
About the b) rule.
--
The following code does not parse because of the newlines that are
interpreted as statement terminator.
for
1..10
{ ... }
But
for (
1.. 10
) {
}
is legit.
See, this is the main, unPerlish thing you're doing. You're enforcing
particular styles upon people, something Perl is proud of *not* doing.
Let's not forget the often occurence of:
$fh = open 'foobar'
or die Can't open foobar: $!;
An implicit semicolon would cause it to croak there.
Also, s/or/$(any if unless for while when ...)/
It would be trivial with a grammar munge to implement this (heck, I
did it with a source filter in Perl 5). Surely CPAN6 (6PAN/CP6AN/??)
will come out with one of these right off the bat, so you could do:
use Grammar::ImplicitSemicolon;
Or something like that, and be done with it.
Luke
Re: newline as statement terminator
Multiline atomic statements just have to be broken at the right place to avoid to break them: Sorry about my English. Let me reformulate. When folding an atomic statement, it becomes two statements or its meaning is unchanged depending if an operand is expected or not at the position of the folding. a + b is equivalent to a + b But a + b are two statements. -- stef
Re: newline as statement terminator
On Tue, 4 Feb 2003, [iso-8859-1] Stéphane Payrard wrote: In the tradition of Perl concision, I would like newline to be a statement terminator everywhere it can: that is when a) the parser expects an operator _and_ b) we are not in the middle of a parenthesised expression. I don't mean to be abrupt here, especially seeing as how this list has been so patient with some of my ideas but... PLEASE NO. The rules you suggest for keeping track of when a semicolon is required sound more confusing than the simple rule of end of statement, put semicolon. I like to break up my long statements in all sorts of arbitrary places, and adding the worries of when a newline might be significant puts a knot in my stomach just thinking about it (literally). Note that, for Perl 6, Larry has already opened the path in his fourth apocalypse: NOTE TO ALLISON RANDAL: in your face-to-face meetings next week, please make sure that Larry Wall isn't really Guido van Rossum with a fake mustache. -miko Miko O'Sullivan Programmer Analyst Rescue Mission of Roanoke
Re: newline as statement terminator
It would be trivial with a grammar munge to implement this (heck, I did it with a source filter in Perl 5). Surely CPAN6 (6PAN/CP6AN/??) will come out with one of these right off the bat, so you could do: use Grammar::ImplicitSemicolon; Or something like that, and be done with it. silly The trick would be getting Perl to not require the semicolon at the end of that use-line. :) /silly serious I agree entirely with what Luke just said in the email I'm replying to. While it's possible to have Perl behave this way, I don't think Perl programmers *in general* would want it. Heck, a lot of us aren't even thrilled about the implicit-semicolon-at-brace-followed-by-newline rule Larry introduced in A4. /serious -- Debbie Pickett http://www.csse.monash.edu.au/~debbiep [EMAIL PROTECTED] You gotta bat your eyes - like this. - _The Little Mermaid_
Re: Language Discussion Summaries
Miko O'Sullivan wrote: Therefore, I propose that members of the language list provide summaries of the discussions in the group. Each summary describes a proposed idea feature of the language, then summarizes the list's feelings on the idea. Different opinions will be presented. The summaries will also attempt to provide a feeling for the weight of opinion, e.g., most people felt this way, some people felt differently, etc. The summaries will also link to the original threads so that readers can peruse the raw data. Go for it. It might not catch on, but it's worth a try. Keep in mind that Piers' summaries already cover a good part of this, but if you do it right you might make his job easier. :) In general, it should probably be the responsibility of the original poster to summarize the thread. Allison
Re: newline as statement terminator
On Mon, Feb 03, 2003 at 06:11:23PM -0700, Luke Palmer wrote: [snip] See, this is the main, unPerlish thing you're doing. You're enforcing particular styles upon people, something Perl is proud of *not* doing. Let's not forget the often occurence of: $fh = open 'foobar' or die Can't open foobar: $!; An implicit semicolon would cause it to croak there No, that case would not cause the inclusion of an implicit semicolon. I certainly should have discussed such cases. But I have covered them in the blanket statement C) and other cases that would also cause the parsing to return an error because I am confident that the parser can handle them. What I said: My proposition could then be expressed informally: Newline is interpred as statement terminator when it makes sense. It does not when : A) in the middle of an expression when an operand is expected B) within a parenthesised expression C) and other cases that would also cause the parsing to return an error Also, s/or/$(any if unless for while when ...)/ It would be trivial with a grammar munge to implement this (heck, I did it with a source filter in Perl 5). Surely CPAN6 (6PAN/CP6AN/??) will come out with one of these right off the bat, so you could do: use Grammar::ImplicitSemicolon; Or something like that, and be done with it. I am certainly confident that in perl6, everyone will be able to bake his own grammar. I am also confident that the grammar will be good enough that we will not have to do it in the general case Luke -- stef
Re: newline as statement terminator
Miko O'Sullivan wrote: NOTE TO ALLISON RANDAL: in your face-to-face meetings next week, please make sure that Larry Wall isn't really Guido van Rossum with a fake mustache. Righto. No reptiles, only jewels and birds. And possibly the occasional snark. ;) Allison
Re: newline as statement terminator
On Mon, Feb 03, 2003 at 08:19:29PM -0500, Miko O'Sullivan wrote: On Tue, 4 Feb 2003, [iso-8859-1] Stéphane Payrard wrote: In the tradition of Perl concision, I would like newline to be a statement terminator everywhere it can: that is when a) the parser expects an operator _and_ b) we are not in the middle of a parenthesised expression. I don't mean to be abrupt here, especially seeing as how this list has been so patient with some of my ideas but... PLEASE NO. The rules you suggest for keeping track of when a semicolon is required sound more confusing than the simple rule of end of statement, put semicolon. As Luke Palmer said, in perl6, semicolon is a statement separator not a statement terminator. So there is no such simple rule in Perl but you are free to imposit it on yourself. Perl allows it but it does not requires it. I like to break up my long statements in all sorts of arbitrary places, and adding the worries of when a newline might be significant puts a knot in my stomach just thinking about it (literally). I agree that be obliged to check the next line to see if the newline is or is not a statement terminator is not the nicest thing. On the other hand, if the programmer is correctly indenting the program it should stand out that the next line is part of the courant statement. print --- # must read the next line to # figure out if new line is statement terminator or not if $condition; Here indentation is a mere clue but has no syntactic meaning. [snip] -- stef
Re: newline as statement terminator
I don't mean to be abrupt here, especially seeing as how this list has
been so patient with some of my ideas but... PLEASE NO. The rules you
suggest for keeping track of when a semicolon is required sound more
confusing than the simple rule of end of statement, put semicolon.
As Luke Palmer said, in perl6, semicolon is a statement separator not a
statement terminator. So there is no such simple rule in Perl but you
are free to imposit it on yourself. Perl allows it but it does not
requires it.
Er. What is the difference between a statement seperator and a
statement terminator for the majority case?
Seperator means I can leave off the last one in a {} b/c there's no
following statement ... But is there any other place I can optionalize
the ; by calling it a seperator vs a terminator?
I like having ;'s at the end of my bits, b/c then I know where a line
ends. When someone's pasting me bad (and I mean BAD) perl5 code, I like
having those ;'s there to tell me what ended where, since (The case i'm
thinking of offhand) was doing a print qq|| that printed out a BUNCH of
things and then ended with an if .. that ; was important b/c I kept
thinking hte if was part of the next line (it was on a seperate line,
making it even more fun)
Yes, this would make that program entirely not work, but I'm sure the new
version wouldn't be much prettier since there'd be no ;s at all
I like to break up my long statements in all sorts of arbitrary
places, and adding the worries of when a newline might be significant
puts a knot in my stomach just thinking about it (literally).
I agree that be obliged to check the next line to see if the newline is
or is not a statement terminator is not the nicest thing.
lookahead parsing is tolerable in a compiler, but in an interpreted/jit
environment, I'd HATE for my code to change meaning b/c i forgot a \n ...
esp if it's in generated code ... e
On the other hand, if the programmer is correctly indenting the program
it should stand out that the next line is part of the courant statement.
print --- # must read the next line to
# figure out if new line is statement terminator or
if $condition;
Here indentation is a mere clue but has no syntactic meaning.
So, is the indentation required as a parser-hint (ewww, I hated mandatory
indents in fortran, and I can't see any good reason to bring them back;
stylistically I still think they're mandated, but not dictated by the
language) or is it just there to help people ?
And why is there a ; there? i presume the is a typo, but since this
whole discussion is getting rid of the ;, I cna't see why it's there ...
Summary: ;'s good, indentation necessary but not parser-graphically
dicatated :o
--attriel
(parsergraphically?)
Re: newline as statement terminator
print --- # must read the next line to
# figure out if new line is statement terminator or not
if $condition;
Yes, let's expand that example, and assume the semicolons optional
where obvious proposal.
sub foo
{
print abcde
if $condition
{
print fghij
}
}
Is this
sub foo
{
# Conditionally print.
print abcde if $condition;
return sub {
# closure, see A4
print fghij;
};
}
or is it
sub foo
{
print abcde; # Always print.
if $condition {
# Optionally print fghij right here.
print fghij;
}
return; # No return value.
}
?
See the problem? Optional semicolons mean that something else has to
take up the syntactic slack, in this case extra keywords or indentation.
Personally, as a Perl programmer, I *like* semicolons. They are the
programming equivalent of the end-of-phrase markers you get in music to
tell your brain to take a breath.
--
Debbie Pickett http://www.csse.monash.edu.au/~debbiep [EMAIL PROTECTED]
You gotta bat your eyes - like this. - _The Little Mermaid_
Re: Language Discussion Summaries
Allison Randal [EMAIL PROTECTED] writes: Miko O'Sullivan wrote: Therefore, I propose that members of the language list provide summaries of the discussions in the group. Each summary describes a proposed idea feature of the language, then summarizes the list's feelings on the idea. Different opinions will be presented. The summaries will also attempt to provide a feeling for the weight of opinion, e.g., most people felt this way, some people felt differently, etc. The summaries will also link to the original threads so that readers can peruse the raw data. Go for it. It might not catch on, but it's worth a try. Keep in mind that Piers' summaries already cover a good part of this, but if you do it right you might make his job easier. :) Hell yes. Actually my summaries run on a different 'clock' to thread summaries; I'd expect thread summaries to get written after a given thread has pretty much died down (or at least started repeating itself too often) whereas my summaries get produced to a weekly timetable, which isn't necessarily the same as the threads (see the last few summaries where the same thread has appeared repeatedly) -- Piers
