[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Adding a Return() function
- From: "Thierry@spoludo" <thierry@...>
- Date: Wed, 17 Dec 2014 11:15:52 +0200
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.
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?
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 <email@example.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.
if y==0 then return nil, "division by zero" end
return x / y
if y==0 then
return nil, "division by zero"
the OP proposal would be:
if y!=0 or Return(nil, "division by zero") then
which i think is much less readable than either of the others, and not
shorter than the first one.