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 ide
> 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"
}
}
>> 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
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
>
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
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'
>
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 su
> 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
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
>
> 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 th
> 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
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
betwee
> > 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
Thats a great idea.
Murat
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 firs
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
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
>
On Mon, 3 Feb 2003, Dave Mitchell wrote:
> $var ??= 'succeeded' :: 'failed';
Aha!
$var && 'succeeded' || 'failed';
Thank you, precedence.
/s
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 b
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 shortc
--- 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.
21 matches
Mail list logo
