On Sun, Feb 05, 2006 at 07:26:09PM -0800, Darren Duncan wrote:
: Part way through writing this, I had a brief chat on #perl6 with 
: stevan (and apparently the meta-model is still quite in flux) and he 
: said my question was related to Larry's "class but undef" idea, and 
: that Larry should talk more about the subject.

Aside from the fact that it's not a class, and not necessarily undef,
"class but undef" is a good name for it.  :-)

I've been calling them prototype objects lately for lack of a
better word.  To me, the Real Class is the object instance hiding
behind .meta.  But when you say bare "Foo" you actually naming a
generic object of the type ^Foo, which I see currently as shorthand
for Foo.meta, and which any object that does Foo can get at if it
needs metadata, including the Foo object itself.  In short,

    Foo.does('Foo')

This is mostly motivated by linguistics rather than computer science,
insofar as types/classes/roles in natural language are normally
represented by generic objects rather than "meta" objects.  When I
ask in English:

    Can a dog bark?

that's equivalent to asking in Perl 6:

    Dog.can('bark')

The "Dog" there is in the same type category as $dog, and specifically
is *not* in the same type category as the class that is managing
the logic behind the scenes.  As a user, I'm thinking about "doggy"
objects, not "classy" objects.  It's the very same kind of linguistic
reasoning that gives us "given" rather than "switch", and "when" rather
than "case".  People want to think about their problem's objects,
not the language implementor's representations of those objects.

Now in the case of .can, we do eventually end up asking the metaobject
whether this objects supports the .bark method, but the point is that
the user doesn't have to keep track of how many metas there are.
Or looking at it the other way, any object can stand in for all its
meta objects.  This is how we think (I think).

Psycholinguistially, every "dog" object in your brain is really a
kind of partially instantiated object that is slowly being filled in
with knowledge about the real world counterpart to your mental model.
Your mental model is never perfect.

The trend in the world today is away from monolithic computers that
either know everything or nothing, and toward programs that have
to work with imperfect knowledge that is generated or downloaded on
the fly.  So I think the modeling view of reality is the sweet spot
for the future, and languages that have to know everything before
they think they know anything are doomed to fail.  Well, not fail,
but have restricted ecological niches, such as rocket science.
(And maybe not even there, as machines get more autonomous.)

So the basic answer to you question is, I think, yes.  If Dog chooses
to always return true for .defined, then (in Haskell terms) it's more
like a Just type than a Maybe type.  Perl 6's objects like to be Maybe
types by default, but you can override it.  (I'm using the Haskell
terms loosely here, of course.)  But the very concept of definedness
is getting mushy in Perl 6.  What we need is more concepts of the
form "Is this *sufficiently* defined for what I want to do with it?"
That's why I proposed "defined according to a particular role" as
one way to ask that sort of question.

Hope this helps.

Larry

Reply via email to