Re: The distinction between "do BLOCK while COND" and "EXPR while COND" should go
> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes:
>> I don't want that to change. I simply want that return (I'm not sure
>> how to phrase this) be able to return only a scalar or an aggregate.
TC> die unless wantarray;
Okay, I'll admit it, again. I find the changing of a comma in what
looks like a list changing into a comma operator because of a caller
several thousand lines away disconcerting.
>> It should be immune from having a scalar context pushed through from
>> the caller and change the commas from a list seperator into the comma
>> operator.
TC> Ok, how are you going to jam a list into a place that only
TC> holds a single thing? Modulo some superpositional silliness,
TC> you aren't. You need a rule for what to do. We have a rule
TC> for that, but you don't like it. It's not sensible that this
TC> rule be applied inconsistently.
I don't want to jam a list into anything. I want it to remain a list.
sub fn { return (3,5,7) }
$x = fn;# I want $x==3
I want to lose the conversion of the ',' into a comma operator when
it is in a return.
-internals is hoping that pushing a single aggregate on the stack
rather than flattening would be a win.
So it might effect the following,
(@foo, @bar) = (@bar, @foo);# exchange
(@foo, $x) = (@bar, (3,5,7)); # $x = 3
The entire thing is in a list context, but the $x imposes a scalar
context on the 'list' at the end. (To keep something of backward
compatablity, it probably would need to act differently if the @
is not in the final position.)
Now here is where it would probably break, and give you a fit trying to
explain it.
($x) = (getpwnam($name))# $x = $name
(@foo, $x) = (&fn, getpwnam($name)) # $x = $>
*sigh*
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 178 (v1) Lightweight Threads
I was wondering, should there be a split between the name and the contents? So that my $a :shared; my $b; $b = $a = &fn; So that access through $a is mediated. Access through $b is "don't do that". Should perl take on the responsibility of coddling the user? Perhaps a warning if the contents of a :shared variable moves into a non-shared variable. Alternatively, the thread doing the moving, somehow takes ownership of the contents, and makes the contents unavailable to any other thread? Thoughts? > "CF" == Chaim Frenkel <[EMAIL PROTECTED]> writes: > "SWM" == Steven W McDougall <[EMAIL PROTECTED]> writes: >>> Not unless it is so declaredmy $a :shared. SWM> Sure it is. SWM> Here are some more examples. SWM> Example 1: Passing a reference to a block-scoped lexical into a thread. CF> The mediation would be activated only if the value is passed via a CF> shared variable. In your case the shared variable is the argument CF> being passed through the thread creation call. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: The distinction between "do BLOCK while COND" and "EXPR while COND" should go
>I don't want to jam a list into anything. I want it to remain a list.
Then it won't fit. Don't you understand? YOU CANNOT LET IT REMAIN
A LIST AND PUT ALL THOSE THINGS IN A SCALAR SLOT.
> sub fn { return (3,5,7) }
> $x = fn;# I want $x==3
Why should it return the first one? It returns the last one!
It's just doing what you told it, which was:
$x = 3;
$x = 5;
$x = 7;
and you're left with 7.
This is not a new concept, nor an isolated one. Here's another list:
$x = @ENV{HOME,USER,TERM};
which is
$x = $ENV{HOME};
$x = $ENV{USER};
$x = $ENV{TERM};
Of course you get the last one. You don't get the first one. You don't
get the count. Sure, there are functions that can do those things, but
these aren't functions who get to be quirky. This is completely expected.
--tom
Re: The distinction between "do BLOCK while COND" and "EXPR while COND" should go
> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes:
>> I don't want to jam a list into anything. I want it to remain a list.
TC> Then it won't fit. Don't you understand? YOU CANNOT LET IT REMAIN
TC> A LIST AND PUT ALL THOSE THINGS IN A SCALAR SLOT.
>> sub fn { return (3,5,7) }
>> $x = fn; # I want $x==3
Let me try once more. I want that fn() to act like
sub fn { my @a = (3,5,7); return @a}
You are letting the scalar context of the caller to bleed through the return
and effect the _syntatic_ meaning of the comma.
TC> This is not a new concept, nor an isolated one. Here's another list:
TC> $x = @ENV{HOME,USER,TERM};
Not the same. I'm only interested in action-at-a-distance. Where there
is a sub and a return in between. I have no objection to that.
TC> Sure, there are functions that can do those things, but these
TC> aren't functions who get to be quirky. This is completely
TC> expected.
To you perhaps. I feel that the syntactical change is unexpected.
But do you any objectsions to making this limited change? When the
EXPR of a return is a literal list, it should not have its comma
changed?
Will my proposal bleed into anything else in the language?
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: The distinction between "do BLOCK while COND" and "EXPR while COND" should go
>>> sub fn { return (3,5,7) }
>>> $x = fn;# I want $x==3
>Let me try once more. I want that fn() to act like
> sub fn { my @a = (3,5,7); return @a}
Oh. You want lists to act like arrays. That's a very big change.
>You are letting the scalar context of the caller to bleed through the return
>and effect the _syntatic_ meaning of the comma.
So what?
>TC> This is not a new concept, nor an isolated one. Here's another list:
>TC> $x = @ENV{HOME,USER,TERM};
>Not the same. I'm only interested in action-at-a-distance. Where there
>is a sub and a return in between. I have no objection to that.
return @ENV{HOME,USER,TERM};
had jolly well not be returning 3. I'm returning a LIST, dang it.
I don't ever expect a list to be an array. Try popping it, for
example.
>TC> Sure, there are functions that can do those things, but these
>TC> aren't functions who get to be quirky. This is completely
>TC> expected.
>To you perhaps. I feel that the syntactical change is unexpected.
>But do you any objectsions to making this limited change? When the
>EXPR of a return is a literal list, it should not have its comma
>changed?
Yes, I object.
The comma is NOT changed. It's doing exactly what a list does.
It never returned an array. You now want (1,2,3) to be an array!!
--tom
Re: The distinction between "do BLOCK while COND" and "EXPR while COND" should go
Think of it this way: you're asking that when you write return WHATEVER; (for various values of WHATEVER) that *sometimes* it's context dependent, and sometimes it's not. Right now, it always is, which is more consistent, predictable, and explainable than the alternative. Or maybe you're asking for the scalar comma operator to no longer return its right-hand operand, which would at best be inconsistent with C. The distance of the context doesn't matter. If I write return fx(); and sub fx in turn uses return fy(); and sub fy in turn uses return fz(); Then all the way down in fz(), you still inherit the context from many stack frames above you. You can argue that context dependency is a bad thing, and that argument would in fact carry some weight. I doubt it would be enough to sway Larry, who has some very fine reasons of his own to have context, but nonetheless, there's certainly something to be said for it. (Though I haven't seen an RFC yet proposing that context be eliminated.) --tom
Re: RFC 178 (v1) Lightweight Threads
> There is a fundemental issue on how values are passed between > threads. Does the value leave one thread and enter the other or are > they shared. > The idea tossed around -internals was that a value that crosses a thread > boundary would have a wrapper/proxy attached to handle the mediation. > The mediation would be activated only if the value is passed via a > shared variable. In your case the shared variable is the argument > being passed through the thread creation call. [...] > If we don't require a :shared on variable anything and everything > has to have protection. If you want the variable to be shared > declare it. [...] > Aha, I get it. -internals has been assuming that one _must_ specify > the sharing. You want it to be infered. > I think that's asking for too much DWIMery. Question: Can the interpreter determine when a variable becomes shared? Answer: No. Then neglecting to put a :shared attribute on a shared variable will crash the interpreter. This doesn't seem very Perlish. Answer: Yes. Then the interpreter can take the opportunity to install a mutex on the variable. - SWM
