Re^20: printing unitialized value of the 'do BLOCK' (EXPRESSION vs TERM vs STATEMENT)

Depending on the definition you take

Yes. I clearly said it doesn't make sense for your definition.

I'd compromise on "statement which can be used like an expression to produce values".

I presume you are saying this is what an if statement is. It's not. You can't count on it returning anything according to the documentation, and a provided example demonstrated this.

Comment on Re^20: printing unitialized value of the 'do BLOCK' (EXPRESSION vs TERM vs STATEMENT) Download Code

Replies are listed 'Best First'.
Re^21: printing unitialized value of the 'do BLOCK' (EXPRESSION vs TERM vs STATEMENT) by LanX (Saint) on Dec 28, 2019 at 17:53 UTC
> You can't count on it returning anything according to the documentation, and a provided example demonstrated this. The only examples I remember seeing demonstrate syntax errors, when `if` isn't used in a statement spot. Do you have an example where `if` doesn't return a value as last statement inside inside a `do`, `eval` or `sub` `{BLOCK}` or similar? Cheers Rolf _{(addicted to the Perl Programming Language :) Wikisyntax for the Monastery FootballPerl is like chess, only without the dice}	[reply] [d/l] [select]
Re^22: printing unitialized value of the 'do BLOCK' (EXPRESSION vs TERM vs STATEMENT) by ikegami (Patriarch) on Dec 28, 2019 at 23:25 UTC
It's all covered by my initial post. It explains that the documentation doesn't define what happens and that it could be implied that it's Undefined Behaviour, it explains what usually happens, and it explains that you can't always count on it happening (in the form of a link to a reply that provides an example where it doesn't happen).	[reply]
Re^23: printing unitialized value of the 'do BLOCK' (EXPRESSION vs TERM vs STATEMENT) by LanX (Saint) on Jan 02, 2020 at 13:30 UTC
Thanks. I consider the now fixed `unless (1)` case a bug derived from improper constant folding optimization. Regarding "undefined behavior" I'd rather say "poorly documented behavior". Returning the result of the last statement is very normal in Lisp ( which has no `return` or any other jump directive in core). Larry was repeatedly very supportive for Lisp constructs, at one "State of the Onion" he even criticized Python for neglecting them. Given that people are actively using this behavior in productive code for over 20 years already, we should rather try to document and test it properly. Cheers Rolf _{(addicted to the Perl Programming Language :) Wikisyntax for the Monastery FootballPerl is like chess, only without the dice}	[reply] [d/l] [select]


Keep It Simple, Stupid
	PerlMonks