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
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, a
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 explic
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
> > a
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 ac
[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 y
> > 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
On Sun, Jan 20, 2002 at 10:58:34PM -0800, Larry Wall wrote:
> : while( my $line = ) {
> : ...
> : }
>
> That still works fine--it's just that $line lives on after the while.
This creeping lexical leakage bothers me. While it might make the
language simpler, the proliferation of
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 = ) {
> > : ...
> > : }
> >
> > That still works fine--it's just that $line lives on after the while.
>
>This creeping lexical leakage bothers m
On Mon, Jan 21, 2002 at 02:44:40PM -0500, Melvin Smith wrote:
> 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 = ) {
> >> : ...
> >> : }
> >>
> >> That still works fine--it's just that $li
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 Conway
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 blo
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 = ) {
I think many pe
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: Th
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 bool
At 03:16 PM 1/21/2002 -0500, Tzadik Vanderhoof wrote:
>It's not the condition you would want to check, it's the variable (e.g.
>$line).
Right, I gotcha. I guess I would rather see it cater to the typical use,
not the atypical. Of course my opinion of typical might differ from yours.
I do feel th
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 = ) {
> > : ...
> > : }
> >
> > That still works fine--it's just that $line lives on after the while.
>
> This creeping lexical leakage bo
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 = ) {
:> > : ...
:> > : }
:> >
:> > That still works fine--it's just that
Melvin Smith writes:
: At 03:16 PM 1/21/2002 -0500, Tzadik Vanderhoof wrote:
: >It's not the condition you would want to check, it's the variable (e.g.
: >$line).
:
: Right, I gotcha. I guess I would rather see it cater to the typical use,
: not the atypical. Of course my opinion of typical might
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 = ) {
> > : ...
> > : }
> >
> > That still works fine--it's just that $line lives on after the while.
>
> This creeping lexical leakage bothers me. W
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,
> not before and not after. I don't see ickyness about making that so.
Exactly!
What we're cleaning up is the ickiness of having things dec
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.
Perl is well known for its non-orthogonality. To say that "A bloc
Ted Ashton writes:
: 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 = ) {
: > > : ...
: > > : }
: > >
: > > That still works fine--it's just that $line lives on after the while.
: >
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>;
>
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 l
David Whipp writes:
: 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.
:
: Perl is well known for its non-or
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,
> > not before and not after. I don't see ickyness about making that s
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 s
Graham Barr writes:
: But are we not at risk of introducing another form of
:
: my $x if 0;
:
: with
:
: if my $one = {
: ...
: }
: elsif my $two = {
: }
:
: if ($two) {
: ...
: }
Then it's just undefined. It's no different from how &&, ||, or ??::
work when you put a
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 = {
> : ...
> : }
> : elsif my $two = {
> : }
> :
> : if ($two) {
> : ...
> :
Michael G Schwern writes:
: In this case I'll take long-term simplicity over short-term
: easy-to-explain rules.
I fail to see what's simpler about it.
: Otherwise we'll be writing this all over the
: place til Kingdom come.
:
: do {
: if my $foo = bar() {
: ...
:
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 = ) {
>> > : ...
>> > : }
>> >
>> > That still works fine--it's jus
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
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 = {
: > : ...
: > : }
: > : elsif my $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 h
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 ma
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 i
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
> : > :
>
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! Simila
> 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 C in list context:
>
> @result = fo
Graham Barr wrote:
> On Mon, Jan 21, 2002 at 03:58:49PM -0500, Michael G Schwern wrote:
Case 1:
> > do {
> > if my $foo = bar() {
> > ...
> > }
> > }
Case 2:
> if ((my $foo = bar()) eq 'foo') {
> ...
> }
>
> if ($foo eq 'bar') {
> ...
> }
Des
In Apocalypse 4, Larry Wall wrote:
|
| In fact, a C of the form:
|
| CATCH {
| when xxx { ... } # 1st case
| when yyy { ... } # 2nd case
| ... # other cases, maybe a default
| }
|
|means something vaguely like:
47 matches
Mail list logo
