Returning none

[C.Laurence Gonsalves]

In comp.lang.python, you wrote:
> clgonsal at keeshah.penguinpowered.com (C.Laurence Gonsalves) writes:
> 
> > It is possible, but more complicated, to make this a compile time
> > error. This would essentially require a function/procedure
> > distinction with restrictions about how you used return in each one.
> > There would still have to be a runtime error for cases where someone
> > tried to get a result from a procedure, but cases like the above
> > example could be caught at compile-time. (The above, being a
> > function, must return a value. Procedures would have to defined in
> > some other way, like using some new keyword "proc" in place of
> > "def")
> 
> Moreover, this would require different syntax when *calling* the
> function/procedure. Let's say, procedure names start with `&' ?

No it wouldn't. It would just be a runtime error if you called a
procedure but tried to get back a value.

So there would be a compile-time error if you incorrectly returned a
value from a procedure, or didn't return a value from a function. It
would be a runtime error if you called a procedure and tried to get a
value from it. So procedure calls would be illegal in expressions, but
this could only be validated at runtime, much like Python currently has
to check to see if that 'function' you're calling is really a function
(or a callable object) after all...

To really tighten the screws, the grammar could be altered so that
expressions are no longer a type of statement. This would prevent people
from calling functions and ignoring the result. 

Then a new keyword could be added which would work much like Modula-3's
'EVAL' (Modula-3 keywords are uppercase, it's not my fault...). Since
there's already a fairly popular function with the name 'eval', a good
name for this new keyword in Python might be 'discard'. Then you could
type:

    discard foo(6)

This would call the function foo, and discard the result. This would
allow you to call functions for their side-effects, and ignore the
result without having to use a dummy variable. It would force people to
do so explicitly, though. The discard keyword would actually take an
expression as its "argument". The idea is that unadorned expressions
statement would no longer be legal, but there would be "procedure call"
and "discard expression" statements to replace them.

I suppose that really is a "different syntax when calling" though. Calls
in a statement context would have to be procedure calls, calls in an
expression context would have to be function calls. Violating either of
these conditions would result in a runtime error.

Incidently, I am aware of the usefulness of being able to type
expressions interactively to get the result. The above modification does
*not* imply the removal of this very useful feature from Python.

I'm only semi-serious about the discard keyword idea though, actually.
Many people would probably hate it since it seems "too strict". I
certainly wouldn't mind it myself though... It would give me more
confidence in the correctness of my code, and the code of others. That
Python tends to be strict in ways which encourage good coding practices
is one of the reasons I like it.

I really *would* like to see a stronger distinction between procedures
and functions though. I really don't think it's right for a Python
function to implicitly return None if I just say "return" or fall off
the end of the definition. 

At the very least I think it should be an error to try and get a return
value from a function that does this. I think it would be better if
there was a separate class of callable objects (procedures) that don't
allow the return of a value, and that function definitions should
require that leaving the function always be done by explicitly returning
some value.

-- 
  C. Laurence Gonsalves            "Any sufficiently advanced
  clgonsal at kami.com                 technology is indistinguishable
  http://www.cryogen.com/clgonsal/  from magic." -- Arthur C. Clarke