On Mar 7, 2006, at 0:31, Allison Randal wrote:
It's overkill to require people to write:
P0 = getstdout
P0.'print'(S1)
Yep. The more that printing to stdout is heavily used in the test
suite. OTOH opcode vs method is merely a matter of what the assembler
is creating. That is: there are 2 notions of an opcode: a user visiable
and usable opcode and an internal opcode as actually implemented in
F<src/ops/core_ops.c>.
E.g.
add P0, P1, P2
is a totally valid user opcode. But there isn't such a thing inisde
Parrot runcores, it translates to the C<infix> opcode. Or 'add I0, 2,
3' is a user-visible/usable opcode only.
Or IO-related:
$I0 = say "ok 1"
say "ok 3"
.local pmc io
io = getstdout
"say"(io, "ok 5")
$I0 = io.'say'('ok 8')
and more variants are valid (albeit experimental) PIR syntax (s.
t/pmc/builtin.t). With the help of a list of 'builtins' the assembler
is creating equivalent (maybe class) method calls from the bare
opcodes.
The more interesting thing is, as already mentioned in a previous f'up:
opcode namespace pollution and overridability of opcodes.
leo
