Abstraction (or, Lambda Calculus for Dummies)

[David E. Manifold]

On Tue, 16 Dec 1997, Fare Rideau wrote:

> > Why is a meta-operator different from a function?  Doesn't higher-order
> > mean functions can be meta-operators?
> Not exactly.
> lambda operates on parsed syntax, not on objects.
> It's a language construct.

I am more interested in the internals of the object system.  From this I
take it that constructors and destructors is what I am talking about.  I
want to be able to write the specification for the metalanguage in Tunes.
This mainly includes "what is the definition of an object?" but also "how
are objects created" and "how do they interact".

You use the term "theory"-- does this mean 'object'?

The way I understand the object system, the user specifies exactly one
object, by defining it in terms of already existing objects.  The
specification consists of multiple meta-objects, each of which is a
constraint, or statement about the object.  The statement is in terms of
objects already known.  The statements, when combined, represent the
object's type.  A function can utilize the object iff its specification
matches or is in some way compatible with the specifications of the
object.  In this way the statements about an object (contained in
meta-objects) control whether an object can combine with a function.

How do constructors and destructors fit in with the above model?  (Mainly,
how do constructors and destructors relate to an object's specification?)

Here is what I understand of variants and invariants:  The invariant is
the object specification, and doesn't change.  Variant is anything
dynamic, like implementation detail or current detected range of a value
(it may be specified to be infinite range, but currently the range is only
1-10).  You suggested in www that you can place stipulations in the
variant part of the specification, for specs that are only temporary.

Is function application a constructor because it returns an object?  
Are functions then also destructors because they make use of objects?  I
assume the answers to both of these two questions are false, because
constructors and destructors are both part of the specification, or type
of an object.

> In expression "(lambda (x) x)",
> you don't apply a function "lambda" to objects "(x)" and "x"!

I was mistaken about the use of lambda.  I thought "basic constructors"
meant the fundamentals of the object system.  I am trying to establish a
complete picture of the tunes metalanguage, the part of the system that is
syntax-less.  The metalanguage is not really linguistic at all, and I do
not know how to design the language part of the system.  But I do want to
model the interaction between objects at the most basic level.  I want to
model reflection in a closed system.  Maybe a system that can go from
source to semantics to source again is reflective.  But my idea of
reflection is a closed object system where the system is self-described
and self-modifiable.  The primitive objects come first, then interface to
the external world.

> Functions operate on objects.

You suggest in Attributes under hll requirements that there is not much
difference between objects and functions.. this then means that you can
simply combine 2 objects that have compatible metaobjects, and neither one
has to be defined as a "function."

Your reply about Attributes I think confirmed what I didn't think was
likely.  Is it simpler to think of attributes as components or members
describing other objects? 

You said:
>Well, the attribute is just as much "part of the object"
>as any other "field" of it. Actually, the other "parts" of the objects
>will have been defined as attributes themselves.

So basically an attribute is a "part" of an object, right?

> > You didn't answer my question: are all functions initially created by
> > abstraction?
> >
> Depends on the syntactic primitives. It has been proved early on
> that instead of using lambdas, you could do everything in terms of
> higher-order combinators. The most well-known set of combinators
> that generate all functions expressible with lambdas is S, K, I:
> 	I x -> x
> 	K x y -> x
> 	S x y z -> ((x z) (y z))
> (proof by double induction on the structure of lambda terms,
> eliminating lambdas from the innermost to the outermost).

What are S, K, and I?

> > Is C++ not reflective because you can not access definitions of a function
> > by other functions?  Is abstraction the key function that accesses the
> > internals of functions, or is it just one?
> Reflection is quite different from abstraction.
> Abstraction is the syntactic capability of defining functions
> out of expressions. Reflection is the capability of going from syntax
> to objects (absorption), and objects to syntax (reification).
> Usual functional programming languages have abstraction and no reflection
> (though LISP dialects often have some reflective features in the form
> of macros, MOPs, or meta-circular interpreters).
> FORTH has reflection (though low-level semantics interfere with it)
> and no abstraction.

If the expression is not syntactic, but already internally represented, as
an expression tree, what is abstraction then?  What operations are
available on the level where syntax is not required?  Previous systems had
programmers take their meaning and encode it to a language.  Tunes allows
programmers to directly express meaning by specifying objects.  One reason
why I am enthusiastic about Tunes is programming without a language.

A syntactical language would be reflective if it had absorption and
reification.  An object system is reflective if objects simply
describe/operate on objects.

The object system behind the HLL is a set of capabilities that describes
all possible languages and methods of inventing new ones.  I call it the
metalanguage...it is this that I am interested in working on and
understanding.

David E. Manifold <tril@bespin.ml.org> http://www.pacificrim.net/~dem/
"...there is no such thing as reality.  Reality only exists in someone's
perceptions, attitudes, beliefs...and nowhere else."
"The world's apparent chaos is only a reflection of our own inner turmoil."
--Michael Gerber, _The_E-Myth_