--- Brent Dax <[EMAIL PROTECTED]> wrote:
> TOGoS:
> # When I say in IMCC:
> #
> # $P0 = $P1 + $P2
> #
> # , I expect it to create a new value and store it
> in
> # $P0, not give me a segfault because I didn't say
> #
> # $P0 = new <figure out what the heck type
> # $P0 is supposed to be based
> # on the types of $P1 and $P2>
> #
> # first.
>
> Then your expectations are wrong.
>
> I think you may be losing sight of the fact that
> most users will *never*
> interact with PASM or PIL directly. Most users will
> have a
> parser/compiler/optimizer between them and PIL--one
> that was written,
> tested and debugged by experts. The few people who
> work with raw
> assembly or IL should know what they're doing.
> While I have no problem
> with IMCC-time warnings about constructs like this
> ("Use of
> uninitialized register $P0 in add"), I don't think
> we should coddle the
> user at this level.
>
> Moreover, there really isn't any way to do what you
> want to do here.
> There is no way for the add opcode to intuit what
> type should be put
> into $P0. That's ultimately the host language's
> decision, not Parrot's,
> and the host language may have complicated rules to
> decide it. And even
> if we did do something like this, we'd be penalizing
> calls to add that
> *do* have correct arguments.
Yes, I realised when I wrote this that it
may be impractical to have add(pmc) ops with
the semantics I suggested (you'd
probably have to add new vtable entries,
for one thing), but the op with the existing
semantics should at least have a different
syntax. As it is, the add(ints) op and the
add(pmcs) ops do very different things (one
has 'set' while the other has 'assign' semantics),
but they look exactly the same. If not at
the PASM level, then they should at least
be different at the IMCC level (":=" and "=", or
"=" and "<-" or whatever for set and assign).
Just because most people that write the stuff are
supposed to know what they're doing doesn't mean
that the interface shouldn't be kept as clean and
consistent (I can spell "consistent", now!)
as possible for those of us (and our
compilers) who *do* work with it, especially
when it doesn't actually cost anything, except
maybe initial development time (Remember: it's
supposed to be Good, not necessarily Quick or
Cheap. Otherwise Parrot'd be done by now :-)
I sense the 'only people who really know
what they're doing wil use this interface,
anyway, so we don't have to make it nice'
attitude in a few other places... most
notably the Windows API. Ever tried to do
a fork() with the Windows API? Compared
to the simplicity of Unix's fork(), the
Windows version just makes me feel dirty.
That's why I try to avoid programming for
Windows. Hint, hint ;-)
But aside from all that, I still think
that the set semantics for add, etc. would
make a lot of sense in many cases, because
the PMC that is being addded will know
how best to return. Adding something to a PythonInt
would return a PythonInt, while adding to a PerlInt
would return a PerlInt. Or a PMC could return
something completely different when you add
something to it. So it wouldn't be the add
opcode deciding what to do; it would be the
PMC. Using the assign semantics the PMC that
you are adding to has no control over what you
end up with (does it?). Sometimes this may be
what you want, But in my view, add with set
semantics will be more common in dynamicly-typed
languages, so it ought to be at least as well
supported. But if not, at least try not to
confuse set and assign, so much. Having to say
what you mean could save compiler writers and
debuggers from a lot of headaches. :-P
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
