Am Mittwoch, 27. September 2006 09:12 schrieb Allison Randal:
> The basic problem is inconsistency. For hand-written code the current
> PIR method call syntactic sugar is mildly annoying. (It'd be nice to
> safely get rid of the quotes around the method name.)
Not easily:
obj.'foo'() # a methodname constant
.local string bar
bar = get_some_meth() # or bar = 'get_some_meth'()
obj.bar() # a method variable
But:
obj.foo() # still a methodname constant
# unless there's a variable 'foo'
To be on the safe side, method (and function) names *should* be quoted. I
don't think that this is inconsistent.
> And when some common language constructs are opcodes and some are method
> calls, the burden of deciding which kind of syntax a particular
> construct should use falls to the compiler writer. There are various
> ways to implement it: a lookup table, a chunk of hard-coded PIR, etc.
> But they all boil down to added complexity.
Well, when I write x86 or ppc JIT code, the burden of deciding, which syntax
to use falls on the compiler write that is me. While we could provide an
introspection API to available opcodes (and args) it still doesn't help much.
The compiler (writer) has to know, what a particular opcode is doing.
When I write code which calls some library function, I've to lookup the docu
and check the function name and the argument it takes. And I've to decide, if
I have an opcode available and use it, or if I've to call a library function.
This is just the usual job when creating a compiler. Introspection would have
little benefit IMHO:
interp = getinterp
info = interp.get_op_info() # hypothetical
$I0 = exists info['gcd'] # do we have a 'gcd' opcode
cl = getclass 'Integer'
$I0 = can cl, 'gcd'
While a compiler could use introspection or tables or whatever, these still
wouldn't help to figure out the semantics of a particular operation.
> Allison
leo
