Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked
 
PerlMonks  

Re: MOPT-03 - identification, part 1

by djantzen (Priest)
on Dec 27, 2002 at 04:49 UTC ( #222467=note: print w/ replies, xml ) Need Help??


in reply to MOPT-03 - identification, part 1

Poor ascii art follows, but I found it helpful to map this out a little bit (pls /msg me if the formatting appears munged):

/ scope ----- / "outside" the entity/ | abstraction | "inside" the entity/ encapsulation | barrier | encapsulation | | identifier/ binding => | | name reference => | =======> | => value/summary \ \ /scope -----

Scope is created by the abstraction barrier insofar as variables and functions defined within the entity itself are inaccessible without, i.e., a lexical variable within a subroutine is accessible only within that subroutine, not to the caller or to other subroutines called from within that unit of encapsulation.

An identifier or name is bound insofar as it merely points to an entity, whereas a name refers if it points across the abstraction barrier to a specific value or summary of the entity.

To dereference is to pull a value or summary across the abstraction barrier to access it directly (or step across the barrier to it, which I guess is an equivalent metaphor), so  my $array_ref = [qw/foo bar/] puts the array itself safely behind the barrier, making $array_ref[0] a violation of encapsulation. Instead, we must say $array_ref->[0] to cross the boundary. Actually, now that I think about this, talking about Perl references muddies the water, doesn't it? Rather, we just mean the use of any variable which results in a taking-hold of the value referenced. So, a better example might just be ordinary string interpolation.

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

I'm still confused about what a summary/value is though. Could you provide a concrete example? Also, does object permanence mean "the same entity" in terms of memory location or content? From the discussion, I'm thinking it's the latter. Or maybe that's just the difference between the entity and it's summary?

In any case, great write up; IMHO the best so far!


Comment on Re: MOPT-03 - identification, part 1
Select or Download Code
Re2: MOPT-03 - identification, part 1
by mstone (Deacon) on Dec 29, 2002 at 23:45 UTC

    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";

    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";

    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();

    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(); }

    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."

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://222467]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others meditating upon the Monastery: (11)
As of 2014-08-22 18:33 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (163 votes), past polls