On Fri, Jan 20, 2006 at 09:35:13PM +0800, Audrey Tang wrote:
: Note that A12 used to say that all Objects does Hash, and %$obj even
: returns private attributes when used inside the class scope.
: Fortunately, S12 doesn't mention anything like that, so I think the
: treatment above is safe.
We still need something to bridge that gap, whether that particular
mechanism is available or not. The p5-to-p6 translator needs to
figure out what to do with things like this:
$x->{whatever}
In isolation, we can't know whether that should translate to
$x<whatever>
or
$x.whatever
So either p5-to-p6 does type inferencing (from some very dynamic p5 code!)
or we fudge it to emit some construct that defers the decision to p6, at
either compile time or run time, but p6 compile time still only works if
we have a compile-time typed $x, which is likely to be undecidable for
a lot of code coming from the p5 universe.
On the assumption that p6 has to make the decision then, we have three
alternatives:
Write $x.whatever, fall back to hash subscript on method call failure
Write $x<whatever>, fall back to method call on non-hash
Write $x.punt('whatever'), and take an extra redispatch hit every time
My original intent was #2, hence the wording in A12. But to speak to
some of Stevan's concernes, there's something going on here which is
not quite "Object does Hash". It's more like "Object can do Hash",
in the linguistic sense that a "Noun can do Verb", but nonetheless
remains a noun. A fallback role is not the same as a normal role.
Maybe there's some way to mixin in a fallback Hash role without
clobbering a real Hash role that is already there, so that if your
Hash container is an object you don't see methods for its keys.
Something like this might also let us distinguish p5ish scalars that
are simultaneously Num and Str from scalars that, say, intrinsically
do Num but can emulate Str in a pinch without caching the result.
I don't think we have a good way of expressing that distinction right
now.
This seems to imply that a given role like Hash could have two default
implementations--one for an actual Hash container, and one that emulates
a Hash by deferring to the Object. It's sort of like a role that can
delegate back to its own object.
For simplicity, we might prefer to leave the Hash role alone as a
normal hash, and provide some way of registering emulation fallback
capabilities, in a tie-ish sort of way, but tied to types instead
of to individual containers, so you could know to look for a FakeHash
role or some such.
But rather than forcing people to register fallbacks, it might be a lot
nicer to establish some intrinsic relationship between a role actually
does the thing and a role that merely fakes it in terms of something else.
But maybe all this is already possible in the current setup, if
role ObjectFakeHash does Hash {...}
role Object does ObjectFakeHash {...}
class Hash does Hash {...}
So ObjectFakeHash would just grab the Hash interface but override the
default implementation. I think that would give us the fallback semantics
I'm looking for without doing great violence to anything else.
But maybe someone can come up with a better way. Maybe we can come
up with some kind of lexically scoped solution instead, if we decide
it's just a language emulation issue. But my hunch is that it's
a deep tagmemic/metaphorical problem we're trying to solve here.
Such issues arise whenever you start making statements of the form
"I want to use an A as if it were a B." The problem is much bigger
than just how do I translate Perl 5 to Perl 6. It's questions like:
What makes a particular metaphor work?
Will the cultural context support use of an A as if it were a B?
How do we translate the user's thoughts to the computer's thoughts?
How do we translate one user's thoughts to another user's thoughts?
How do we know when such a translation is "good enough"?
How do we know when our mental model of an object is adequate?
How do we know when the computer's mental model of an object is adequate?
What does adequate mean in context?
Will the culture support partially instantiated objects? :-)
That's tagmemics, folks. The main problem with tagmemics is that, while
it helps you ask good questions, it doesn't give you easy answers for 'em...
Anyway, I'd still kinda like to find some way to use an object
"as if" it were a hash, partly to solve my immediate problem, but
also because I think a good computer language might address the
"as if" problem better than any of them do currently. In general,
hypotheticality is still something that humans are much better at
than computers. We're still just nipping around the edges with "fail",
"let", environmental variables, STM, roles, and junctions. But we'll
not get true AI until a computer can understand a sentence like
In a hole in the ground there lived a hobbit.
as if it were a human. A human has the ability to execute "new Hobbit"
before "class Hobbit" is even defined! Humans are not much into
strong compile-time typing, and when they are, we call it stereotyping,
or racism, or whatever.
Well, I'm just blathering now...
Larry
