Re: print ambiguity

"Paul Prescod" <[email protected]> wrote in message
news:[email protected]...
> Mark Hahn wrote:
>
> > If you put the word "print' on a line by itself, the meaning is
ambiguous
> > under the new function-as-command proposal.  It could mean evaluate the
> > print function object or it could mean call it.  Since the Parser
doesn't
> > know which objects are functions, much less which are commands, it would
> > have to decide at parse time whether all labels by themselves on a line
> > should be attribute evaluations or command function calls.  We need to
> > decide.
>
> Maybe the parser shouldn't make the decision. The parser could generate
> some kind of POSSIBLE_COMMAND opcode and then the runtime VM could ask
> the object whether it is a command or not. If it is, it calls it. Else,
> it just returns it. With proper caching and object layout this could be
>   a relatively quick check.

Agreed.

I don't need to change the parser.  The bytecode is already special
(OP_CMDCALL).

I will put a kludge into my function calling code to revert to just
returning the object instead of throwing an exception in that situation.  It
will be easy.   There is no way to avoid having the compiler set up the code
for a function call though.  At each function call the object could change
from being a command to not being a command.