On Fri, Jan 18, 2008 at 09:41:01PM -0800, Geoffrey Broadwell wrote:
> The error message from parrot when there is a spelling mismatch between
> a function call and the function's actual declaration is accurate but
> confusing:
>
> *****
> $ cat > foob.pir
> .sub main :main
> foo()
> .end
>
> .sub foob
> print "Hello\n"
> .end
>
> $ ./parrot foob.pir
> Null PMC access in invoke()
> current instr.: 'main' pc 7 (foob.pir:2)
> *****
>
> Of course, once you've seen this error message once or twice, you won't
> soon forget the diagnosis. For the sake of beginners however it would
> be nice to add a hint to the message, for example:
>
> "Null PMC access in invoke(); misspelled sub name in function call?"
I fear this error message may actually send a beginner down a false
trail. This particular error occurs anytime we attempt to call
a sub that cannot be located in the current lexical/namespace/global
symbol table. So, there could be other causes for the error besides
a simple misspelling.
Better might be a way to get the function call to report
"Unable to find function 'foo'". However, a PIR statement like
C< foo() > gets translated into a set of instructions like:
set_args PC1
find_name P0, "foo"
get_results PC1
invokecc P0
The "Null PMC access in invoke()" except gets thrown at the
point of the invokecc call, at which point we no longer have
convenient access to the name.
So, the options I see at this point are to modify the find_name
opcode to throw an exception when asked to locate a non-existent
symbol (note that this is somewhat counter to the way we've been
heading), or to have the PIR compiler generate code to check
the result of find_name and throw an exception.
Pm
