Skip to content
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

Rakudo allows assignment to elements of a readonly array... except when it doesn't #1745

Open
p6rt opened this issue May 4, 2010 · 8 comments
Labels

Comments

@p6rt
Copy link

p6rt commented May 4, 2010

Migrated from rt.perl.org#74902 (status was 'open')

Searchable as RT74902$

@p6rt
Copy link
Author

p6rt commented May 4, 2010

From @masak

<masak> rakudo​: sub foo(@​a) { @​a[1] = "NOES" }; my @​a = <OH HAI>;
foo(@​a); say ~@​a
<p6eval> rakudo 1eef08​: OUTPUT«OH NOES␤»
<masak> is this supposed to be allowed?
<pmichaud> masak​: I haven't seen a clear answer to that question.
<masak> pmichaud​: ISTR there was some wording in the spec about the
readonlyness stretching 'one level down' into arrays/hashes, but I
can't find it now, despite trying.
<pmichaud> masak​: From an implementation perspective, I see nothing
but pain in trying to make that happen.
<masak> pmichaud​: anyway, this already fails​:
<masak> rakudo​: sub foo(@​a) { @​a[0, 1] = <OH NOES> }; my @​a = 0, 1; foo(@​a)
<p6eval> rakudo 1eef08​: OUTPUT«Cannot assign to readonly value [...]
<masak> so something is inconsistent, at least.
* masak submits rakudobug

@p6rt
Copy link
Author

p6rt commented Oct 21, 2012

From @coke

On Tue May 04 14​:13​:17 2010, masak wrote​:

<masak> rakudo​: sub foo(@​a) { @​a[1] = "NOES" }; my @​a = <OH HAI>;
foo(@​a); say ~@​a
<p6eval> rakudo 1eef08​: OUTPUT«OH NOES␤»
<masak> is this supposed to be allowed?
<pmichaud> masak​: I haven't seen a clear answer to that question.
<masak> pmichaud​: ISTR there was some wording in the spec about the
readonlyness stretching 'one level down' into arrays/hashes, but I
can't find it now, despite trying.
<pmichaud> masak​: From an implementation perspective, I see nothing
but pain in trying to make that happen.
<masak> pmichaud​: anyway, this already fails​:
<masak> rakudo​: sub foo(@​a) { @​a[0, 1] = <OH NOES> }; my @​a = 0, 1; foo(@​a)
<p6eval> rakudo 1eef08​: OUTPUT«Cannot assign to readonly value [...]
<masak> so something is inconsistent, at least.
* masak submits rakudobug

Behavior changed​:

sub foo(@​a) { @​a[1] = "NOES" }; my @​a = <OH HAI>;
OH HAI

sub foo(@​a) { @​a[0, 1] = <OH NOES> }; my @​a = 0, 1; foo(@​a)
OH NOES

--
Will "Coke" Coleda

@p6rt
Copy link
Author

p6rt commented Oct 21, 2012

The RT System itself - Status changed from 'new' to 'open'

@p6rt
Copy link
Author

p6rt commented Aug 27, 2015

From @coke

On Sat Oct 20 18​:12​:38 2012, coke wrote​:

On Tue May 04 14​:13​:17 2010, masak wrote​:

<masak> rakudo​: sub foo(@​a) { @​a[1] = "NOES" }; my @​a = <OH HAI>;
foo(@​a); say ~@​a
<p6eval> rakudo 1eef08​: OUTPUT«OH NOES␤»
<masak> is this supposed to be allowed?
<pmichaud> masak​: I haven't seen a clear answer to that question.
<masak> pmichaud​: ISTR there was some wording in the spec about the
readonlyness stretching 'one level down' into arrays/hashes, but I
can't find it now, despite trying.
<pmichaud> masak​: From an implementation perspective, I see nothing
but pain in trying to make that happen.
<masak> pmichaud​: anyway, this already fails​:
<masak> rakudo​: sub foo(@​a) { @​a[0, 1] = <OH NOES> }; my @​a = 0, 1;
foo(@​a)
<p6eval> rakudo 1eef08​: OUTPUT«Cannot assign to readonly value [...]
<masak> so something is inconsistent, at least.
* masak submits rakudobug

Behavior changed​:

sub foo(@​a) { @​a[1] = "NOES" }; my @​a = <OH HAI>;
OH HAI

sub foo(@​a) { @​a[0, 1] = <OH NOES> }; my @​a = 0, 1; foo(@​a)
OH NOES

These are now the same (both in nom and glr, even)

12​:10 < [Coke]> m​: sub foo(@​a) { @​a[1] = "NOES" }; my @​a = <OH HAI>; foo(@​a); say ~@​a
12​:10 <+camelia> rakudo-moar 47ddca​: OUTPUT«OH NOES␤»
12​:10 < GLRelia> rakudo-moar 345953​: OUTPUT«OH NOES␤»
12​:11 < [Coke]> m​: sub foo(@​a) { @​a[0, 1] = <OH NOES> }; my @​a = 0, 1; foo(@​a); say ~@​a;
12​:11 <+camelia> rakudo-moar 47ddca​: OUTPUT«OH NOES␤»
12​:11 < GLRelia> rakudo-moar 345953​: OUTPUT«OH NOES␤»

Closable with tests?
--
Will "Coke" Coleda

@p6rt
Copy link
Author

p6rt commented Aug 27, 2015

From @masak

<masak> [Coke]​: no.
<masak> [Coke]​: I think you misunderstood the goal of the ticket.
<masak> [Coke]​: the spec said (and still *says*, I think) that the *contents* of the array parameter are readonly. that's what the "one level down" thing refers to.
<masak> [Coke]​: However, the default forces any container argument to also
<masak> be treated as an immutable value. This extends down only one level;
<masak> an immutable container may always return an element that is mutable if
<masak> it so chooses.
<masak> S06​:718
<synbot6> Link​: http://design.perl6.org/S06.html#line_718
* masak adds this to the ticket

@p6rt
Copy link
Author

p6rt commented Dec 16, 2015

From @jnthn

On Thu Aug 27 09​:22​:02 2015, masak wrote​:

<masak> [Coke]​: no.
<masak> [Coke]​: I think you misunderstood the goal of the ticket.
<masak> [Coke]​: the spec said (and still *says*, I think) that the
*contents* of the array parameter are readonly. that's what the "one
level down" thing refers to.
<masak> [Coke]​: However, the default forces any container argument to
also
<masak> be treated as an immutable value. This extends down only one
level;
<masak> an immutable container may always return an element that is
mutable if
<masak> it so chooses.
<masak> S06​:718
<synbot6> Link​: http://design.perl6.org/S06.html#line_718
* masak adds this to the ticket

Resolution​: not this Christmas. Short discussion​:

http://irclog.perlgeek.de/perl6/2015-12-16#i_11729677

In my view, the best hope of doing this is probably through some static analysis, which we can introduce conditional on language version, so it'd be opt in by language version and we'd be able to not break existing code that didn't opt in to using that version.

For the meantime, the ticket survives, but is off the xmas list.

@p6rt p6rt added the Bug label Jan 5, 2020
@JJ
Copy link

JJ commented May 7, 2020

This still a problem, far as I can tell.

@masak
Copy link

masak commented May 7, 2020

Given jnthn++'s verdict above, I think this issue is now a feature request, not a bug report.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants