Re: Adding a Return() function

Personally I find the "if" statement so much more readable, that I'd discard any alternative on that ground alone.

I agree with Javier - input validation and failfasts at the beginning of the function, with if statements.

Having "return" as an _expression_ would also cause a mess of difficult to understand behaviors.. like for example :

> return nil, Return(0) -- does it return.. what ?

> f(Return(0)); -- is f ever called ?

> t[Return(0)] = f(Return(1)) + f(Return(2)) -- .. what ?

If there's really a need to save keystrokes on such scenarios I'd suggest a "on" pattern which just takes a single statement instead of a block like:

> on divisor == 0 return nil, "error"

> on divisor == 0 do return nil, "error"

or something like that.

But then, I don't see such a need :)

Of course, my 2 cents.

On Wed, Dec 17, 2014 at 10:15 AM, Thierry@spoludo <thierry@spoludo.com> wrote:

Well, we have assert and we have error and no macro nor typing constraints . Error has a ‎parameter for the level of error, but it rather means depth in the callstack.
‎Assert returns the evaluation and is fatal.
Maybe there is room for generalization ‎at the language level?

So I will Just muse on not deeply thought concepts.

<- condition [, message [, level ]] -> ‎ non fatal, optional (by interpreter command line argument) , ie error like, but returns the condition evaluation like assert or exit the function with nil, message

‎<+ condition [, message [, level ]] +> same as above but always checked
‎
‎<* condition [, message [, level ]] *> same as assert but with a level parameter.

Why not ‎keep the function call or use a keyword ? Mainly because of willing to cover type contraints but introducing keywords may be better.
‎
function ‎divide(
a,
b <+ b ! = 0 and b +>, -- implicit assign in grammar context,
fn <- type(fn) == "string" and fn -> -- can we check both constraint always and return cumulated messages ? Can we avoid "and fn"?
)
‎ local f = <* ‎io.open(fn, "w"), "can't write in "..fn *> -- keep assert keyword as an alias?
return a/b
end
‎
Original Message
From: Javier Guerra Giraldez
Sent: mercredi 17 décembre 2014 10:03
To: Lua mailing list
Reply To: Lua mailing list
Subject: Re: Adding a Return() function

On Wed, Dec 17, 2014 at 2:25 AM, Hao Wu <wuhao.wise@gmail.com> wrote:
> I think OP's point is return can be a function so it can be baked into the
> _expression_ v.s. a single statement, for simplicity.

yes, i was just pointing a third option that is shorter, more readable
(IMHO) and currently valid.

when any function has some 'fail fast' condition(s), i like to add one
or more such 'guard lines' as close to the top as possible. also, if
the "then" clause ends with a return, i don't put an "else" for the
rest of the function, avoiding useless indentation and too many 'ends'
at the end.

function division(x,y)
if y==0 then return nil, "division by zero" end
return x / y
end

instead of:

function division(x,y)
if y==0 then
return nil, "division by zero"
else
return x/y
end
end

the OP proposal would be:

function division(x,y)
if y!=0 or Return(nil, "division by zero") then
return x/y
end
end

which i think is much less readable than either of the others, and not
shorter than the first one.

--
Javier