Front page | perl.perl5.porters |
Postings from March 2023
Re: Pre-RFC Deep constants
Thread Previous
|
Thread Next
From:
Branislav Zahradník
Date:
March 13, 2023 12:57
Subject:
Re: Pre-RFC Deep constants
Message ID:
CAB=rbOk4smjQepNBe+YybuxVNj1z9LXFy6ytSrR_PpwYuPykTQ@mail.gmail.com
>
>
>>> try:
>>> my $foo = { bar => 1 };
>>> my %hash = (foo => $foo);
>>>
>>> use Hash::Util qw(lock_hash_recurse);
>>> lock_hash_recurse(%hash);
>>>
>>> $foo->{baz} = 2;
>>>
>>
>> This does what I expect:
>>
>
> Attempt to access disallowed key 'baz' in a restricted hash at t.pl line
> 7.
>
> Is that not what you wanted? Am I missing something still?
>
No it is not - it makes non-constant expression constant.
Therefore there is in an idea to do MVP only with constant expressions.
Though I will expect it otherwise:
my %hash : const = { foo => { bar => 1} };
my $foo = $hash{foo};
- now $foo is constant
>
>
>>
>>> such MVP is imho idea, why not exporting existing behaviour via unified
>>> :const ?
>>>
>>
> BY "MVP" do you mean "Minimum Viable Product"?
>
Yes
>
>
>>
>>> sub var :const { "foo" }
>>> my $var : const = "x";
>>>
>>> my %hash : const = ...
>>> my @array : const = ...;
>>>
>>> For mentioned MVP, constant expression should be only:
>>> - literal values
>>>
>>> my $foo : const = { bar => { baz => 1 } };
>>>
>>
> Not sure I follow you here. I suspect you and I are using different
> definitions of "literal values". To me the 'bar' key is being assigned a
> reference, so I wouldnt call it a literal value. If you mean that we should
> restrict constants to unreferenced objects we could probably do that if we
> wanted, but typically perl does not distinguish between a value containing
> a hashref and an anonymous hash constructor. The only way we could would
> be to check its refcount, which we tend to avoid.
>
Literal value, as I used it, is a value directly specified in source code
(where its dump is same as its source)
>
>
>>
>>> - another already constant structure
>>>
>>> my @foo : const = (1, 2, 3);
>>> my $bar = { foo => \ @foo };
>>>
>>
> Yeah so that would blow away using the refcount to determine if the value
> was legal.
>
>
>> - it is constant function or its product
>>>
>>> sub foo : const { ... }
>>> my $bar : const = { foo => \& foo, result => [ foo ] };
>>>
>>
> Yeah, now you are getting into the realm of turing completeness. I can't
> imagine us ever implementing this.
>
- sub is const if declared such (so syntax is limited to attribute)
- const function may return only const expression. Its call may be
optimized out (ie: do not rely on side-effects)
- reference to const expression is const expression as well
I don't see anything complex here, but who knows :-)
I'm still speaking "behaviour" instead of "implementation" (first one is
singleton, second, as Perl programmers especially know, is multiton)
>
>
>>
>>> for MVP, const ffunction may imply :prototype () (like use constant does)
>>> later it may accept const arguments only
>>>
>>
> I think it is unlikely anyone would ever be able to code this, and I dont
> think it would be reasonable to base an RFC on expecting to achieve it.
>
>
> Much more likely would be to simply say "we deep copy the entire constant
> structure at initialization time, and make the copy read-only/constant for
> the lifetime of the process".
>
>
As far as I understood discussion that's exactly a point of proposed MVP to
postpone deep-copy decision.
There definitely will be conflict with lazyness and write-once values later.
There is also another aspect of const values: declaring const context.
Any expression can be used as constant in such context, but later it will
get its original behaviour back.
I have a gut feeling that split this into multiple steps is a good idea.
Yves
>
> --
> perl -Mre=debug -e "/just|another|perl|hacker/"
>
Thread Previous
|
Thread Next