function as command (from WIKI)

"Mark Hahn" <[email protected]>
Newsgroups gmane.comp.lang.prothon.user
Message-ID <[email protected]>
Mark Hahn:

The function as command feature was an approved feature until Serge ran into
this FunctionAsCommandProblem (was this page). So the feature was unapproved
and moved back to the consideration list.

The problem was that print (1+2)*3 had to be parsed as a print function
because of the parens following the word print, giving unexpected results.

I now have a proposal to fix the problem. If we add a symbol before every
function-as-command that tells the parser it is a command, we can avoid the
ambiguity. I will propose the right caret because it looks like a command
prompt but other symbols could be used. The use of this symbol now means the
command rule will drop any reference to parens. The rule will simply say any
line that starts with the command-symbol and the command function is a
command line and the command extends to the end of the line:

    >print (1+2)*3  # this is a command

This change also makes the functon-as-command feature more explicit, which
is always a good thing. We could almost drop the requirement for the
command_ attribute flag and allow any function to do this.
I'd like to fix an unrelated command problem in this proposal also. Commands
functions should always return None. This will fix the console double
printing problem. I don't know why we didn't propose this before.

Serge:
> is Perlish :-) Seriously if I have to type >, why not type two characters
( and ) ? What I want from the function as command feature is to fail in the
face of ambiguity. It's OK to fail at run time. If commands are required to
return Void (not None) then you can intercept any attribute access of Void
object and raise VoidError("You're attempting to do something with the
result of a command, consider using parens")

Mark Hahn:
> Seriously if I have to type >, why not type two characters

It not only saves typing two characters but also it solves the console
double printing problem.
What I want from the function as command feature is to fail in the face of
ambiguity.

The ambiguity print (1+2)*3 returns a string since it is a function. (I will
keep telling you and Paul it is a function, not a command, until it finally
sinks into your brains <grin>). So this ambiguity could not be detected with
your None trick


Serge:

> It not only saves typing two characters but also it solves the console
double printing problem.

I lost you here. Are we talking about console problems? Anyway, what I
suggest also "solves" console problems.

> I will keep telling you and Paul it is a function, not a command, until it
finally sinks into your brains <grin>

I knew that since the beginning <wink>, you were arguing with Paul. What I
pointed out is that my example silently did something surprising. It took me
a couple of minutes to realize what's going on.
So this ambiguity could not be detected with your None trick.
If function is also required to return Void it will work. print (1+2)*3 will
be interpreted as (print(1+2))*3, and once print returns Void, Void * 3 will
raise an exception VoidError('Don't mess with Void'). Yes it's a trick. It
can be potentially dangerous to introspection. However > symbol is a
flie-dirt <wink>, it's ugly.



mark:

Your proposal said "If commands are required to return Void". You never
mentioned the idea of having functions returning Void. I thought the whole
idea of making print a function was to be able to print something and have
the function return what was printed as the return value of the function.
Would print-as-function still be useful without returning the printed string
as the return value?

Yes, PrintWithNoReturnValue would fix all our problems.

Serge:
Does anyone know how Ruby solves this mess?
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.