Re: Luerl

[Jay Carlson <nop@...>]

On Wed, Feb 22, 2012 at 4:56 PM, Jay Carlson <nop@nop.com> wrote:
> On Tue, Feb 21, 2012 at 3:47 PM, Axel Kittenberger <axkibe@gmail.com> wrote:
>
>> Immutable, but with lazy evaluation would be my ideal (that is some
>> values are calculated only when needed, but stored as cache. But since
>> the table is immutable, and the function obviously should not depend
>> on side-effects, the result is constant as well).
>
> I see two interesting and broadly applicable patterns, and I'd
> probably use them both if I had them close at hand:

[...]

> Memoizing final tables: mft = lazy_final(m, {k=2})

Before I forget, this is almost a special case of a pattern seen in
larger systems: a module-local view/decoration of values. The idea is
that a grouping of functions would like to keep some private state
around about a value. They don't necessarily trust other code to get
at this, and they certainly don't want to mutate the value itself. So
notionally, all the code which wishes to share common information
shares an private value, call it "aspect"; they can hide it however
they like. The operation they then want is something like:

  v[aspect::key]    or v::aspect[key]
  v.aspect::key    or v::aspect.key

Behind the scenes this is all weak tables--unless you have some very
cooperative values of v. (Unlike $"" this is not a serious suggestion
for fresh syntax; it's just a notation.)

One example of this is utf8 validity. assert_utf8(s) really wants to
privately decorate s with s::utf8.is_valid. As it happens there are
some reserved bits left in Lua string internals so this is one of
those rare cases of a cooperative v(ictim).

Jay