Re: Garbage collection durint pcall.

[Francisco Olarte <folarte@...>]

Coda:

On Mon, Jun 3, 2019 at 8:59 PM Coda Highland <chighland@gmail.com> wrote:
> On Mon, Jun 3, 2019 at 4:33 AM Francisco Olarte <folarte@peoplecall.com> wrote:
...
>> I'm asuming when the PUC guys say "accesible=live" they mean it, I'm
>> not even assuming slots or anything similar exists.
> This is, I think, the crux of the disagreement here.
> I will agree with you: as long as the documentation is written the way it is, such an optimization would be noncompliant with the standard.

Thanks, for proving me I have stated it in an understandable way, I
was beginning to distrust my ability to express myself.
>
> However, I think the point you're missing is that this is a discussion of "but what if it wasn't documented that way?" Because the documentation can be changed, and that would open up avenues for optimization by relaxing certain guarantees. Yes, this would introduce a point of incompatibility with existing code, but Lua has never once claimed that compatibility across minor releases (as opposed to point releases) was guaranteed.

No, I haven't missed it. I tried to state I'm ok if liveness /
collectablity / whatever definition is changed, as long as it is
documented, but I think there is some vocal chunk of the community
which thinks behaviour could be changed WITHOUT docummenting it
clearly as a breaking change ( I define that as a change which can
break code, not neccessarily breaks it ).

> This would be inconvenient to you, no doubt, as you have code that depends on the current behavior. But part of the discussion of such a change would also need to include "what other changes would be necessary in order to support this use case?"

Minor inconvenience. Very minor, the deployments I do include a frozen
copy of the interpreter, I'm careful with this. As I only use lua
hosted, it is easy to pack it. And I also only link lua static, to
avoid dlpath problems.

> I assert that a "retain" decorator (whether using the <> syntax of const or toclose, or using some wrapper function along with <toclose>) would address your concerns, if this suggested change to the specification were to be pursued.

I'm thankful for a proposal, but Ithink it is not needed. I think
normal behaviour, uncollectable till end of scope ( end of scope
renders local inacessible ), is nice, and is what many languages do.
If you want to render it inaccessible you a mechanism, nested scopes,
which I think are still allowed, and is what is used on other places,
no need to reinvent the wheel.

> In light of this fundamental lack of alignment on the underlying intent of the discussion, the rest of this argument has been fairly meaningless.

Not for me, but the conclussion has been unfortunate.

Regards.
   Francisco Oalrte.