Larry Wall [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] writes:
[...]
: How does one enforce the no side-effects rule, and how deeply does it
: traverse?
Dunno. Could warn or fail on assignment to any non-lexical or
non-local lexical as a start. Maybe we could warn or fail on method
Larry Wall [EMAIL PROTECTED] writes:
Piers Cawley writes:
: Yeah, that's sort of where I got to as well. But I just wanted to make
: sure. I confess I'm somewhat wary of the ';' operator, especially
: where it's 'unguarded' by brackets, and once I start programming in
: Perl 6 then
:
:
Piers Cawley [EMAIL PROTECTED] writes:
Larry Wall [EMAIL PROTECTED] writes:
Piers Cawley writes:
: Yeah, that's sort of where I got to as well. But I just wanted to make
: sure. I confess I'm somewhat wary of the ';' operator, especially
: where it's 'unguarded' by brackets, and once I
Larry wrote:
: One way to do that would be to define POST and NEXT to return their
: own (single, closure) argument. So then you could write:
:
: NEXT POST { ... }
As long as everyone realizes that that return happens at compile
time...
Sorry, yes, I should have been explicit
On Sunday 20 January 2002 21:00, Damian Conway wrote:
Bryan C. Warnock asked:
Since the parentheses are no longer required, will the expressions
lose or retain their own scope level? (I'm assuming that whatever
rule applies, it will hold true if you do elect to use parantheses
anyway.)
Larry Wall writes:
: This is only slightly less problematic than
:
: NEXT $coderef;
:
: which in turn is only slightly less problematic than
:
: if $condition $coderef;
Actually, that'd probably have to be:
if $condition, $coderef;
Still not sure if that has any possibility of
[EMAIL PROTECTED] writes:
: On Sunday 20 January 2002 21:00, Damian Conway wrote:
: Bryan C. Warnock asked:
: Since the parentheses are no longer required, will the expressions
: lose or retain their own scope level? (I'm assuming that whatever
: rule applies, it will hold true if you do
Err. Expressions don't have their own scope level, even in Perl 5.
They do in block conditional expressions.
But that's a property of being in a block conditional, not of being an expression.
And, yes, it's going away in Perl 6.
Damian
In light of Apo4, I thought I'd re-ask this question. Is the following still
the approved idiom, or will we have a nice little /[A-Z]+/ thingie:
sub foo
{
temp $SIG{__WARN__} = sub {
warn $(timestamp) $@\n
}
warn hello
}
Dave.
--
Dave Whipp, Senior Verification Engineer,
Fast-Chip
At 12:32 PM 1/21/2002 -0500, Michael G Schwern wrote:
On Sun, Jan 20, 2002 at 10:58:34PM -0800, Larry Wall wrote:
: while( my $line = FILE ) {
: ...
: }
That still works fine--it's just that $line lives on after the while.
This creeping lexical leakage bothers me.
Why all the fuss? Often, you would *want* to access that lexical after the
loop terminates, for instance to check how it terminated.
-Original Message-
From: Michael G Schwern [mailto:[EMAIL PROTECTED]]
Sent: Monday, January 21, 2002 2:59 PM
To: Melvin Smith
Cc: Larry Wall; Damian
On Mon, Jan 21, 2002 at 03:02:06PM -0500, Tzadik Vanderhoof wrote:
Why all the fuss? Often, you would *want* to access that lexical after the
loop terminates, for instance to check how it terminated.
In most cases you don't want that to happen, usually the life of the
lexical is only the
At 03:02 PM 1/21/2002 -0500, you wrote:
Why all the fuss? Often, you would *want* to access that lexical after the
loop terminates, for instance to check how it terminated.
Why would you want to check it when the condition is typically boolean?
while( my $line = FILE ) {
I think many
It's not the condition you would want to check, it's the variable (e.g.
$line).
-Original Message-
From: Melvin Smith [mailto:[EMAIL PROTECTED]]
Sent: Monday, January 21, 2002 3:15 PM
To: Tzadik Vanderhoof
Cc: [EMAIL PROTECTED]
Subject: RE: Night of the Living Lexical (sequel to Apoc4:
At 03:14 PM 1/21/2002 -0500, Melvin Smith wrote:
At 03:02 PM 1/21/2002 -0500, you wrote:
Why all the fuss? Often, you would *want* to access that lexical after the
loop terminates, for instance to check how it terminated.
Why would you want to check it when the condition is typically boolean?
Thus it was written in the epistle of Michael G Schwern,
On Sun, Jan 20, 2002 at 10:58:34PM -0800, Larry Wall wrote:
: while( my $line = FILE ) {
: ...
: }
That still works fine--it's just that $line lives on after the while.
This creeping lexical leakage bothers
On Mon, Jan 21, 2002 at 03:26:30PM -0500, Ted Ashton wrote:
:
:Thus it was written in the epistle of Michael G Schwern,
: On Sun, Jan 20, 2002 at 10:58:34PM -0800, Larry Wall wrote:
: : while( my $line = FILE ) {
: : ...
: : }
:
: That still works fine--it's just that $line
On 2002.01.21 18:32 Michael G Schwern wrote:
On Sun, Jan 20, 2002 at 10:58:34PM -0800, Larry Wall wrote:
: while( my $line = FILE ) {
: ...
: }
That still works fine--it's just that $line lives on after the while.
This creeping lexical leakage bothers me. While it
On Mon, Jan 21, 2002 at 12:50:38PM -0800, Larry Wall wrote:
: What's the chance that it could be considered so?
In most other languages, you wouldn't even have the opportunity to put
a declaration into the conditional. You'd have to say something like:
my $line = $in;
if $line
On Mon, Jan 21, 2002 at 03:27:29PM -0500, Casey West wrote:
So you're suggesting that we fake lexical scoping? That sounds more
icky than sticking to true lexical scoping. A block dictates scope,
not before and not after. I don't see ickyness about making that
so.
Perl5 already fakes
At 12:50 PM 1/21/2002 -0800, Larry Wall wrote:
In most other languages, you wouldn't even have the opportunity to put
a declaration into the conditional. You'd have to say something like:
I grudgingly agree here. Where did this shorthand come from anyway?
The first time I ever used it was C++
Michael G Schwern writes:
: On Mon, Jan 21, 2002 at 03:27:29PM -0500, Casey West wrote:
: So you're suggesting that we fake lexical scoping? That sounds more
: icky than sticking to true lexical scoping. A block dictates scope,
: not before and not after. I don't see ickyness about making
On Mon, Jan 21, 2002 at 03:58:49PM -0500, Michael G Schwern wrote:
On Mon, Jan 21, 2002 at 03:43:07PM -0500, Damian Conway wrote:
Casey wrote:
So you're suggesting that we fake lexical scoping? That sounds more
icky than sticking to true lexical scoping. A block dictates scope,
On Mon, Jan 21, 2002 at 01:01:09PM -0800, Larry Wall wrote:
Graham Barr writes:
: But are we not at risk of introducing another form of
:
: my $x if 0;
:
: with
:
: if my $one = ONE {
: ...
: }
: elsif my $two = TWO {
: }
:
: if ($two) {
: ...
: }
Then
Graham Barr wrote:
But I have lost count of the number
of times I have wanted to do
if ((my $foo = bar()) eq 'foo') {
...
}
if ($foo eq 'bar') {
...
}
To be contrasted with:
while (my($k, $v) = each %h1)
{
...
}
while (my($k, $v) = each %h2) # error?
{
...
}
MS == Melvin Smith [EMAIL PROTECTED] writes:
MS At 12:32 PM 1/21/2002 -0500, Michael G Schwern wrote:
On Sun, Jan 20, 2002 at 10:58:34PM -0800, Larry Wall wrote:
: while( my $line = FILE ) {
: ...
: }
That still works fine--it's just that $line lives on
At 04:12 PM 1/21/2002 -0500, Uri Guttman wrote:
MS lives on, ... creeping lexical, I feel the same way, we must
find some
MS way to kill these... :)
well, larry looks at it differently and what he said on the cruise makes
Well we had a go, but our kung fu powers were no match for
Graham Barr writes:
: On Mon, Jan 21, 2002 at 01:01:09PM -0800, Larry Wall wrote:
: Graham Barr writes:
: : But are we not at risk of introducing another form of
: :
: : my $x if 0;
: :
: : with
: :
: : if my $one = ONE {
: : ...
: : }
: : elsif my $two = TWO {
: : }
Michael G Schwern wrote:
In this case I'll take long-term simplicity over short-term
easy-to-explain rules. Otherwise we'll be writing this all over the
place til Kingdom come.
do {
if my $foo = bar() {
...
}
}
I'm surprised no one else has
On Monday 21 January 2002 11:14, Larry Wall wrote:
So I'm not terribly interested in going out of my way to make statement
blocks parse exactly like terms in an ordinary expressions. If it
happens, it'll probably be by accident.
That's fine. (And I agree.) All I really cared about was map,
On Monday 21 January 2002 11:27, Larry Wall wrote:
Compound statements in Perl 5 do have an implicit {} around the entire
statement, but that has nothing to do with the required parentheses
around the expressions, other than the fact that we're doing away with
both of those special rules in
On Mon, Jan 21, 2002 at 01:38:39PM -0800, Larry Wall wrote:
Graham Barr writes:
: On Mon, Jan 21, 2002 at 01:01:09PM -0800, Larry Wall wrote:
: Graham Barr writes:
: : But are we not at risk of introducing another form of
: :
: : my $x if 0;
: :
: : with
: :
: : if my
Nicholas Clark writes:
: On Fri, Nov 09, 2001 at 09:14:10AM -0800, Larry Wall wrote:
: NaN is merely the floating-point representation of undef when your
: variable is stored in a bare num. And if you declare a variable as
: int, there may well be no representation for undef at all!
Hmm. A hyperdwim operator. So that means that
@result = @a ^=~ @b
is the same as
@result = map - $a; $b { $a =~ $b } (@a; @b)
Or something resembling that that actually works...
Hmm. I suppose it could be argued that a Cfor in list context:
@result = for @a; @b -
In Apocalypse 4, Larry Wall wrote:
|
| In fact, a CCATCH of the form:
|
| CATCH {
| when xxx { ... } # 1st case
| when yyy { ... } # 2nd case
| ... # other cases, maybe a default
| }
|
|means something vaguely
35 matches
Mail list logo
