develooper Front page | perl.perl5.porters | Postings from March 2006

Re: how should %^H work with lexical pramas

Thread Previous | Thread Next
From:
Nicholas Clark
Date:
March 28, 2006 14:34
Subject:
Re: how should %^H work with lexical pramas
Message ID:
20060328223425.GN32132@plum.flirble.org
On Tue, Mar 28, 2006 at 11:18:39PM +0100, hv@crypt.org wrote:
> Nicholas Clark <nick@ccl4.org> wrote:
> :Thanks to Robin's insight about passing %^H to eval, lexical pragmata work
> :almost perfectly. As I understand it, the only thing missing is that code
> :can't tell at runtime what the relevant compile time state of lexical pragmata
> :was.
> [...]
> :So how should all this stuff work? I think there are actually two hashes, or
> :things-with-a-hash-interface that need to exist. A read only thing that
> :reflects the hints in force at the time of compilation of this statement.
> :(This can be slow, but probably needs to be memory efficient). And a
> :read/write thing which reflects/affects the compilation of the immediate
> :lexical caller, if they are in compile time and we're in run time.
> :
> :Is this sane? If so, what are they called? And how best does the "read only"
> :thing track any updates to the state of the read/write thing? And store them
> :efficiently?
> 
> I'm not sure whether it's sane or not. Is the storage requirement restricted
> to a) a copy of each unique set of values seen in %^H, plus b) a pointer
> somewhere in the optree for each time it changes? If so, it would seem
> sane enough as long as checking whether this is a new "unique set of values"
> is fast.

I don't exactly know.
I was assuming that having the read/write thing as a tied hash means that it
could (for example) maintain a generation count on writes/deletes, which
would make it fast to checking whether things had changed.
(Seems you're thinking generation count too)

> Without the uniqueness check, there is a potential explosion of storage
> requirement: if the hash ends up containing any real bulk, every tiny
> change to it requires another copy of the bulk.

Yes, this is my concern.

> Or is there a third way? Some combination of (under the hood) local() and
> 'upvar', using a generation counter? That would probably qualify for
> 'slow but memory efficient'. And if we can avoid bothering to keep them
> when they won't be needed that would be even cooler (but that's probably
> a 'sawampersand' trap, better avoided).

Possibly jumping ahead to implementation - run time reading of the frozen
state of %^H is likely to be rare, so I was wondering if holding a single
linked list of HE structures without actually having a hash.

In turn, it should be possible to hold a back reference up to the outer
enclosing lexical scope, so each scope needs only hold a vector of the
changes. Deletions could be stored by having a value of PL_sv_placeholder.

But I'm not sure if I'm jumping the gun here, and also I'm not sure how much
work it is to get to the point of being able to generate that sort of
structure. With it in place, reading it via magic on %^H is relatively
trivial.

Nicholas Clark

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About