Re: print ambiguity

On Sat, Jun 26, 2004 at 06:28:48AM -0700, Paul Prescod wrote:
> 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.

I haven't been following the list for a few months, so I apologize if
I'm rehashing old ground, but I don't understand why we're even
contemplating this.  "() = function call" is clear, unambiguous, easy to
code, easy to explain, easy to read, and doesn't have any weird corner
cases to worry about.  The only benefits I've seen for allowing bare
function calls is that it saves a few keystrokes (bah, bot worth it) and
is somehow "cool" (not seeing it).

Hmm, I guess I should look through the archives and get some context...
Dig, dig.

Aha.  Ok, one more use is backwards compatibility.  That's not a bad
one, I guess.

But the last thing I see in the archives before this thread was Mark
agreeing the proposal was dead, on the 17th.  Then, out of nowhere:

> The print keyword has been removed and replaced by a print function.
> The function requires parentheses for now until I implement the
> "function-as-command" feature.

Obviously I missed some discussion between then and now.  How did the
proposal get revived?  Can I request we kill it again?  Requiring a
whole new opcode seems like overkill.

Joe