NICE summary.. bravo!

• I suppose that means then that a closure is a way of exposing a scoped variable without bringing it across the abstraction barrier.

Sort of.. A closure contains a variable whose binding was set in a specific evaluation context. The variable retains that binding, even after it leaves the context where the binding was defined. A closure makes an entity accessible outside the scope where it was defined, so I'd say it exposes the entity, not the variable per se.

• I'm still confused about what a summary/value is though. Could you provide a concrete example?

Sure.. the string "hello, world.\n" is a value. We can put it into a script:

    "hello, world.\n";
[download]

but we can't do anything with it. It just sits there. Even if we use it by passing it to a function:

    print "hello, world.\n";
[download]

it's still inaccessible to the rest of the script. We can't do anything else with "the value we just printed". If we want to use the same value in more than one place, we need to put that value inside an entity, then give that entity a name:

    sub string {
        return ("hello, world.\n");
    }
    print string();
[download]

The name 'string' is an identifier, the function it's bound to is an entity, and the string "hello, world.\n" is a value.

• Also, does object permanence mean "the same entity" in terms of memory location or content?

'Memory location' is closest, but that carries all sorts of baggage specific to a given runtime environment.. it can't be a hardware location, because virtual memory systems shuffle things all over the place; it can't be a logical address, because garbage collectors tend to move things around; yadda yadda yadda.

Object permanence means that we can assume the name "string" will stay bound to the function that returns "hello, world.\n" until we explicitly re-bind it. As a counter-example, imagine a buggy compiler that sometimes confuses identifiers of the same length. The script:

    sub f1 { return ("hello, world.\n"); }
    sub pi { return (3.14159); }
    
    for (1..10) {
        print f1();
    }
[download]

could print any combination of "hello, world.\n"s and "3.14159"s. That would be a violation of object permanence, and would make the compiler useless as anything more than a random number generator.

Object permanence is one of those concepts that's so obvious, and so easy to take for granted, that thinking about it takes work. It's like trying to see air: the whole concept seems meaningless.. unless you're an astronomer, or live in L.A.

Okay, now in applying this further to Perl specifically, is a list (in distinction from an array or a hash) an entity? It seems to me it is not, but rather a value like your string "hello world.\n" that must be placed within an entity in order to be usable.

Also, where do anonymous entities, that is, anonymous subroutines and datastructures, fit in here? Are these entities that are not bound to a name, but rather have only references? Or are such things bound still in the theoretical sense, with the difference between named and anonymous thingies meaningful only at the language level?

• Okay, now in applying this further to Perl specifically, is a list (in distinction from an array or a hash) an entity? It seems to me it is not, but rather a value like your string "hello world.\n" that must be placed within an entity in order to be usable.

If I'm understanding you correctly, the kind of list you're talking about would be a value, and yes, you'd store it in an entity like an array or a hash.

• Also, where do anonymous entities, that is, anonymous subroutines and datastructures, fit in here? Are these entities that are not bound to a name, but rather have only references? Or are such things bound still in the theoretical sense, with the difference between named and anonymous thingies meaningful only at the language level?

First version.. an anonymous thingy is an entity, and the reference is the value of that entity. An anonymous entity has no bindings until we create one for it.

In practical terms, we have raw symbols, things that live in the storage heap, entries in a symbol table, and strings that we use in our code. The things in the storage heap encapsulate raw symbols, and the entries in the symbol table give us programmatic access to things in the heap.

The raw symbol is a value. We probably associate it with some human assumption, but it doesn't exist in the computer until we encapsulate it with an entity.

The thing in the heap is an entity. It encapsulates a value, which puts the symbol into the computer.

The entry in the symbol table is a binding. It gives us the power to access an entity whenever and wherever we want (subject to the scope limits of the binding itself).

The string we use in our code is the identifier. It's one field of the symbol table entry, and it's the thing we actually see when we look at a piece of code and think, "variable."