On 2017-12-31 23:21, bartc wrote:
On 31/12/2017 22:09, Ben Bacarisse wrote:
No, you missed the point and did not address the question. You said (now
cut)
| If I thought introducing functions, whether local or not, as a way of
| avoiding goto was worth doing, I would do so.
but I'm not sure you know if it's worth it or not. So here's my
question again: what language (or languages) were you using when you
concluded that it was not worth using local functions to avoid gotos?
Maybe you had a bad experience from some language that did it badly.
What makes you think I had a bad experience? I posted a version using
Python a few hours ago (which needs the local function to be moved to
work properly).
The same example works in my language (one of them anyway), but I still
find a quick goto the simplest thing to do especially when the code is
not complete so I don't know what will be added or changed or moved,
which will be harder as soon a specific sequence is extracted into a
function.
Also, what would be the duplicated code is seen to 'belong' to one of
the options, rather than be anonymous.
(Here is the same example in my static language:
https://pastebin.com/raw/dX2FNK7a
fn1 uses goto. fn2 uses a local function (not very demanding here so it
works). fn3 uses the special 'block-call' feature which I no longer use
(but I haven't yet got rid of it).
I prefer fn1 and fn3 because the code stays inline. If I had some
inspiration for a better feature then I'd have fn4 and maybe fn5 too.)
The compiler could inline automatically, or you could be explicit:
proc fn2(int a)=
inline proc f123=
println "One"
println "Two"
println "Three"
end
case a
when 1 then
f123()
when 2 then
println "Four"
else
println "Other"
f123()
esac
end
(or possibly "inline f123=").
[snip]
OT: if "case ... esac" and "if ... fi", why not "proc ... corp"? :-)
--
https://mail.python.org/mailman/listinfo/python-list
