Front page | perl.perl5.porters |
Postings from March 2023
Re: Pre-RFC Deep constants
Thread Previous
|
Thread Next
From:
demerphq
Date:
March 13, 2023 13:21
Subject:
Re: Pre-RFC Deep constants
Message ID:
CANgJU+WykxViVbotubnUtHZjOc0YwsouR9PyAan+iSM=KgchRQ@mail.gmail.com
On Mon, 13 Mar 2023 at 13:57, Branislav ZahradnÃk <happy.barney@gmail.com>
wrote:
>
>>>> 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.
>
I think I follow your intent. But Perl doesn't really make the distinction
I think you want. There is a concept of a "const" opcode, but it is pretty
simple and doesn't include complex data structures..
> 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
>
No. $foo is a copy of a $hash{foo}. To make it constant you would have to
say so. Perl makes variables mutable by default.
> such MVP is imho idea, why not exporting existing behaviour via unified
>>>> :const ?
>>>>
>>>
>> BY "MVP" do you mean "Minimum Viable Product"?
>>
>
> Yes
>
Ok. This is an unusual application of that term but sure, I get you.
>
>
>>
>>
>>>
>>>> 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)
>
I would be surprised if perl ever learned to do that like that. Consider
the problems you open up.
my $foo : const = { "b"."a"."r" => { "b"."az" => 2-1 } };
Would $foo be the same in both cases?
>>>> - 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 :-)
>
You are welcome to try to implement it. Have you had a look at our grammar
and toker yet? :-)
> I'm still speaking "behaviour" instead of "implementation" (first one is
> singleton, second, as Perl programmers especially know, is multiton)
>
I dont know what you mean by these terms. I am familiar with "singleton"
with objects, where a class constructor always returns the same object, but
I have never heard the term "multiton" before. I guess you mean "not
singleton", but since this isnt an object I am not sure what you mean by
singleton in this context.
>
>>
>>>
>>>> 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.
>
I see some folks talking about what they would like to have, without really
addressing how they might have it, how it would integrate with the
language, or what it really means in terms of implementation. One of the
problems with this kind of discussion is that the internals often dont work
as people might wish, and things that might seem like they should be simple
things are actually in practice anything but simple. It is good to
brainstorm and say "I would like X", but it also needs to be grounded in
the practical reality of things.
To give you a totally off-topic example. I would like it so that if I
created an XS symbolic ALIAS and there were no other numbered aliases that
ParseXS would not add the dXSI32; declaration that it adds when an XS
definition contains an ALIAS declaraton. On the face of it, this should be
a simple thing. But in practice the way that ParseXS is implemented means
that achieving this goal would probably require a *substantial* rewrite of
ParseXS.
That is for a *very* minor change to software that performans a relatively
simple set of tasks.
What you guys are talking about here is a substantial change to parts of
the language that relatively few people understand at all.
>
>
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.
>
I think you should spend some time working with our internals. Until you do
you won't have a good grasp of the relationship between what you ask for
and what likely is actually acheivable with reasonable investment levels
and will probably spend more time talking about stuff that likely will
never happen, while not doing the things that you could that might cover
80% of what you want. That last 20% can end up being 1000 x the cost of
the first 80%.
I say this all with the greatest respect, and no sarcasm. I'd love for us
to have better support for "constants", it just isnt' that simple a story,
or frankly we likely would already have them.
cheers,
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
Thread Previous
|
Thread Next