Python grammar..

[Delaney, Timothy]

> >> "Delaney, Timothy" <tdelaney at avaya.com> wrote in message
> >> news:mailman.992393599.3573.python-list at python.org...
> >>     ...
> >> > way to do it - a subroutine may or may not return a value, at its
> >> > discretion, and I should be able to ignore any returned value.
> >> 
> >> Yes, but if I were designing a language today, I think I would
> >> request you to be EXPLICIT about "ignoring the return value" --
> >> explicit is better than implicit.  It IS an occasional cause of
> >> errors in Python (particularly with newbies) that an expression
> >> statement's value is silently and implicitly ignored...
> >> 
> >> 
> >> Alex
> >
> >So you would prefer that functions whose return value is ignored must
> > be called with a keyword ... such as in VB
> >
> >	call aFunction()
> >
> >Personally, I absolutely hate this.
> 
> Seems like you could do it the other way around...add a bit of
> something to the function def to say "this is a procedure".  Should
> you actually want to do such a thing... (it may be the path to the
> dark side, a la "static final private void deranged lunatic spam()"
> ...)

This goes back to my original argument, that there should be no distinctions
between subroutines which return a value, and those that don't.

We've had this before (see procedure and function in Pascal, sub and
function in VB). I hate it.

Python does the Right Thing (TM) IMO - one way of defining a subroutine,
which may or may not (explicitly) return a value (all Python functions
implicity return None if no other value is specified). The result of the
subroutine call can be ignored.

However, the most important thing is that whatever is correct in the
language must be enforced. VB is particularly bad for this - calling a
function with a single parameter as

	function a (b)
	end function

	a 1	' OK
	a(1)	' memory leak

but both are syntactically correct. To avoid the memory leak, you must do

	call a(1)

A 2-parameter function (or sub) cannot even be called like that ...

	function b (a, c)
	end function

	b 1, 2		' OK
	b(1, 2)		' syntax error
	call b(1, 2)	' OK

VB is the most pathological case I can think off at the moment, and it
serves as a good argument that there should be one and only one calling
convention.

Tim Delaney