Mailing List Archive: void vs. procedure (was: Re: :writer return)

On 2024-02-17 10:51, Darren Duncan wrote:
> FWIW, from a general language design perspective, I prefer those
> languages that make functions and procedures very structurally
> different routines in how they are declared. So functions must return
> a value and be invoked within expressions, and procedures must not
> return a value and must be invoked as statements. Examples of
> languages like this include SQL and Pascal. In that context, there is
> no "void" result type, instead you have a "procedure".

A procedure-call can still end in failure,
so it further depends on the definition of "return value".

Some functions use out-of-domain values to return error status.
I don't like that, IMO return value and state must be kept separate.

As Perl subs kan return lists, one could use
the first element for the return value
and the second element for the status:

my ($rv, $err) = mysub(....);

But then mysub() needs to use wantarray()
(which actually means wantlist())
to find out what it should return.

Procedures generally have side effects.
Procedures can be allowed to change the contents of ("output") parameters,
which is much like a return value.

Functions are cleanest if they don't have side effects.
But for example memoization already blurs that.

-- Ruud

On 2024-02-17 3:37 p.m., Ruud H.G. van Tol via perl5-porters wrote:
>
> On 2024-02-17 10:51, Darren Duncan wrote:
>> FWIW, from a general language design perspective, I prefer those languages
>> that make functions and procedures very structurally different routines in how
>> they are declared. So functions must return a value and be invoked within
>> expressions, and procedures must not return a value and must be invoked as
>> statements. Examples of languages like this include SQL and Pascal. In that
>> context, there is no "void" result type, instead you have a "procedure".
>
> A procedure-call can still end in failure,
> so it further depends on the definition of "return value".
>
> Some functions use out-of-domain values to return error status.
> I don't like that, IMO return value and state must be kept separate.
>
> As Perl subs kan return lists, one could use
> the first element for the return value
> and the second element for the status:
>
> my ($rv, $err) = mysub(....);
>
> But then mysub() needs to use wantarray()
> (which actually means wantlist())
> to find out what it should return.
>
> Procedures generally have side effects.
> Procedures can be allowed to change the contents of ("output") parameters,
> which is much like a return value.
>
> Functions are cleanest if they don't have side effects.
> But for example memoization already blurs that.

Yes. I kept things simpler in my statement above. But a more expanded version
is: From a general language design perspective, functions should be pure and
not have side effects, and return values are determined just by arguments.
While anything with side effects would be a procedure, and if that procedure has
outputs to the caller it can be through reference/inout parameters. As for
indicating errors, depending on what one prefers, this could be an output
parameter or a thrown exception. Typically one would expect errors/exceptions
to come from procedures and not functions, unless indicating inappropriate
arguments or divide by zero or out of memory or such. I also don't like the
idea of wantarray/etc and feel if one wants different behavior for different
calling contexts like that they should be separate routines with different
names. Anyway this thread is more of a tangent and I likely won't take the time
to discuss it further. -- Darren Duncan