[Types-sig] Re: Meta-classes discussion starter

[John Skaller]

I admit great confusion at all this meta-class stuff.
I don't see it as any kind of realistic meta-programming.

Here's why. Consider a single type 'object' onto which we
can attach attributes or functions intended to be methods.

        class object: pass

already has the first property, I'm not sure about the 'new'
module, but it isn't hard to implement something (in C) that keeps
a dictionary of functions, and converts them to bound methods
on lookup. [binding the first argument is a special case of Currying
which is a special case of the lambda function .. which therefore
subsumes the notion of a bound method]

        Now consider a factory function which makes these
objects. What is it? It is just a constructor like an __init__
method, except that it also attaches methods to the object.

        And that is it. :-) There is no such thing as a class :-))
It is nothing more than a function which makes objects.

        Bases are accounted for by simply
calling 'base' factory functions before calling
more derived ones: any 'polymorphism' is nothing more
than replacement.

        The point? meta-programming has nothing to
do with classes, because they don't exist. Only functions
are of any consequence.

        And what is required for meta-programming is now
easy to see: it is the ability to (dynamically) generate
these factory functions.

        Currently, Python has very crude meta-programming
support: the exec statement. Something more structured
than generating strings and compiling them is desirable.
But what is needed is not meta-classes, but built-in primitives
designed to facilitate dynamic construction of functions.
For example, a primitive to compose two functions (in series),
[called composition], to 'compose' them in parallel [called
product formation], and to compose them as a multiplexor 
or switch [called a union or sum].

        It can be shown that these constructions,
together with a few functors like delta(x) = (x,x),
are enough to construct all functions [given a library
of primitives to start with].

        If we had these kinds of constructions in python,
we could build functions which generate functions more
easily than we can today [using exec, or by emulating
these things with classes]. And then we would have
a better meta-programming system.

        I'm not against 'encapsulating' these meta-functions
in 'meta-classes', I'm just pointing out that classes aren't
fundamental, at least in Python. 

        Of course ... once you realise all this, the distinction
between 'a function' and 'a function that produces an object'
and 'a function that produces an object which is a function' ...
etc just falls away because all functions produce objects.

        So there is only one kind of entity required.
Not an infinite regress of classes, meta-classes,
meta-meta-classes, etc.

        In fact, one can do better -- and dispense with
objects altogether: they're just a special case of functions. :-)

        Or, you can turn that around, and consider functions
as a special kind of object: and my very point is that we need
primitives to operate on this kind of object and we don't
have them.
-------------------------------------------------------
John Skaller    email: skaller@maxtal.com.au
		http://www.maxtal.com.au/~skaller
		phone: 61-2-96600850
		snail: 10/1 Toxteth Rd, Glebe NSW 2037, Australia