New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
:= inconsistent semantics #5532
Comments
From zefram@fysh.org
In the above, the := binding operator exhibits two very different I would expect := to have consistent semantics, unaffected by parameter -zefram |
From @timoThe := operator only has one behaviour/semantics in this example. timo@schmand ~> perl6 -e 'my $a = 3; sub ss1(Scalar $s, $nv) { say Does that help clear things up a little? I'm not sure what mechanism causes the example where Scalar is supplied |
The RT System itself - Status changed from 'new' to 'open' |
From zefram@fysh.orgTimo Paulssen via RT wrote:
Huh, there is indeed a difference there that I wasn't aware of. Thanks.
In this respect, tt1() is behaving the way I expect, and tt0() looks like This issue has some slight resemblance to [perl #128409] and [perl Is there some way I missed to get access to the content of a Scalar? -zefram |
From @timoOn 04/08/16 20:09, Zefram wrote:> Is there some way I missed to get
Aye, you can .<> the value to "decont" it, which will give you the |
From zefram@fysh.orgTimo Paulssen via RT wrote:
Doesn't work as an lvalue:
Has some value for reading, at least. -zefram |
From @timoOn 08/04/2016 08:31 PM, Zefram wrote:
That should be very obvious; I may have communicated |
From zefram@fysh.orgTimo Paulssen via RT wrote:
How? Specifically, in the situation where I have a Scalar as a value, -zefram |
From @timoOn 08/04/2016 08:47 PM, Zefram wrote:
Well, assignment is implemented by calling .STORE on the scalar. Don't It was not correct to say "only assign to scalars", as there's also The assignment operator is the operator to store into a Scalar. I'm getting the feeling we're not getting through to each other :) |
From zefram@fysh.orgTimo Paulssen via RT wrote:
That's not usable in the way I'd expect:
The assignment operator requires an lvalue on its lhs. Where I have a
Yeah. Let me try to make it clearer. In the above situation, with $ perl -lwe '$a = 3; "$b = 5", unsurprisingly, doesn't achieve it: that leaves $a untouched, -zefram |
From @pmichaudOn Thu, Aug 04, 2016 at 09:36:18PM +0100, Zefram wrote:
So are you looking for...? my $a = 3; $b = 5; # Assign 5 to $b (which is also $a) Pm |
From zefram@fysh.orgPatrick R. Michaud wrote:
No. I want a writable reference that I can pass around as a value, -zefram |
From @pmichaudOn Thu, Aug 04, 2016 at 09:54:54PM +0100, Zefram wrote:
"writable reference" --> "Scalar" "store in a data structure" --> "bind using :=" I think that using := is the canonical way to do these sorts of operations:
More generally -- when I last checked Perl 6 doesn't really have "references" in the same style as Perl 5 -- i.e., objects that can be passed around and are magically transparent when you need them to be and opaque when you don't. So far I think we've been able to use binding to do all of the things that Perl 5 references allowed (but more cleanly and efficiently). Pm |
From zefram@fysh.orgPatrick R. Michaud wrote:
That's not going to pass well through anything that treats the data
if I then do my @d = @c.map({ $_ }) then @d[2] is not an alias of @c[2] or $a. It's also quite inconvenient my $flange_width; There are multiple computations to perform, which are done by similar To do this with := means that I can't create @computations in a neat table my @computations = ( Note that related items (output location and formula, for a particular I suppose I could add an extra level of data structure: create a sub ref_to(Mu $a is rw) { my @s; @s[0] := $a; @s } But that seems perverse, when the Scalar object itself is visible to
I'm not particularly looking for the same style. I'm looking for the
I'm not clear what you're referring to here. The way I interpret those -zefram |
Migrated from rt.perl.org#128842 (status was 'open')
Searchable as RT128842$
The text was updated successfully, but these errors were encountered: