Front page | perl.perl5.porters |
Postings from March 2023
Re: Pre-RFC Deep constants
Thread Previous
|
Thread Next
From:
Branislav Zahradník
Date:
March 14, 2023 08:41
Subject:
Re: Pre-RFC Deep constants
Message ID:
CAB=rbOnvrfE9OOVof2tBkntLoH9jboAQOKrOtC=qgSL_rGDLHA@mail.gmail.com
>
>
>> 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.
>
+1
Good point to address - not only constant variable but also constant value
>
>
>> 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.
>
Why unusual? Perl is a product to sell as well, and currently it doesn't
sell well :-)
Sell doesn't need to mean money, whole open source is about different
primary reward.
>
>
>>
>>
>>>
>>>
>>>>
>>>>> 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?
>
Ok, nitpicking :-) Yes, as Dave pointed out little bit earlier, there is
such thing as constant folding.
>
>
>>>>>
>>>>
>> 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? :-)
>
Definitely I did look, I'm still trying to implement GLR parser :-)
(side note here - to be able to finish GLR parser I may need little help -
basically I need to produce libtoke.so)
>
>
>> 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.
>
>
multiton is named singleton, you can choose which singleton to use.
I'm not starting discussion what is an object, whether programming terms
can be used do describe outside world ... :-)
>
>
>> 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.
>
>
I agree with those internals.
But I will never agree with "design only features what we can implement".
I prefer nice design of language (as expected goal) even if some features
will not be implemented yet.
Often it happens, that you get few expected parts from multiple features
resulting into internals change which becomes much cheaper than 1000x.
> cheers,
> Yves
>
> --
> perl -Mre=debug -e "/just|another|perl|hacker/"
>
Thread Previous
|
Thread Next