"enclosures" and "encapsulations"

[band]

obtheory.txt has a definition for what are called enclosures. In ob.txt lines 43 ff. describe what is called an "encapsulation". The function ob.e in obtheory.txt looks to me just like the function ob.e in ob.txt. Why is it not called an "enclosure"?

I think I am confused about what an "enclosure" is. I see what the functions ob.a and ob.b do when the argument is an enclosure, or I think I do. Is this just a matter of definition in obtheory.txt and use in ob.txt?

[orcmid]

Yes, that's right, obtheory.txt is definitive. I should not use encapsulation in ob.txt. No useful purpose and when actual encapsulation is represented, I will have made a mess.

Thanks for catching that.

I'll see what I can do to make enclosure more understandable.

The kind of idiomatic nature and intended use is as follows.

A singleton, x, has it be by definition that ob.b( x ) = x. With respect to ob.b, that can be taken as signifying a single thing. When it is also the case that ob.a( x ) = x, it must be the case that x. is an individual. If that is not the case, then it is the case that ob.a( x ) = y where x = ob.e( y ). In effect, with respect to this idiomatic usage, ob.e( y ) determines a single ob, x, that is kind of a wrapper around y, whatever the structure of y happens to be. In that case, ob.a(ob.e(y)) = y.

[band]

Thanks for the reply. Here is my current state:

I am confused right now about how to understand ob.b.

ob.c and ob.e seem to make sense.

And ob.a also seems to make sense as a kind of selector or let-me-look-inside function. But ob.b; what is that thing and what does it do?

I understand that you are being definitive. So perhaps my confusion is that I want to project some kind of understanding from programming and data structuring on these innocent s and the functions.

[orcmid]

@band See if 0.1.7 changes help concerning how ob.a and ob.b together provide for list-processing idioms.

One can compose structures, using ob.c and ob.e such that, when z is a pair-sequence intended to implement a list,, ob.a(z) yields the first member and ob.b(z) yields the remainder. Typically, if z is a singleton, then the list is exhausted/empty.

Those who know LISP or SCHEME will recognize similar arrangements involving car, cdr, and cons, although the ‹ob› mathematical structure is definitely not the same as an equivalent for LISP.

It is important to recognize this as idiomatic and not inherent in ‹ob›, no matter that ‹ob› affords such representations by design.

Has this been helpful? What additional questions come up?

[band]

Yes. Quite helpful. I did notice the similarity of ob.a to CAR in Lisp. ob.b looks like a CDR when applied to a pair. And pairs of obs can be constructed from any of the obs (individual, enclosure, pair), so an ob data structure can have a number of different elements. Is this right?

I still need to think about enclosures and the defined effects of ob.a and ob.b. The definitions are clear. I guess I want to see an example of them in action.

[orcmid]

In (#23 section 2.3) there is illustration of functional-pseudo-code for a function, finder, that illustrates searching through a list structure where ob.a determines the current first member and ob.b determines the remainder. This is an idiomatic interpretation. It exploits the fact that obs are asymmetrical and that we can differentiate between pairs, enclosures, and indiividuals from structure alone. A way to ensure that one cannot "fall through" the end of a list is to use any singleton as the list ending and use ob.b as the selector for navigating through such a list.

Another part of the idiom is in the ending singleton being used to provide a default/ending result via the ob.a of it. That's how LISP's AV lists are represented, instead, where the list beads are of form value :: feature or the final ob.e(value) such that ob.a gets the value of a finder result either way.

This is all rather arbitrary and pragmatic. I favor structuring Ob this way precisely because, having fixed the choice of primitive notions, these applications/idioms now fall out.

The creation of an oMiser script ^finder, is also demonstrated by progressive rewriting, showing how obap.A and obap.B are results of comparisons with applicative interpretations as selectors of continuation scripts.

There are further demonstrations in boole.txt and ones that represent functional combinators in combinators.txt, section 3.