Icon+Unicon/Intro: Difference between revisions

odds and ends ... &fail considered harmful
(→‎Graphics, Network Messaging, etc.: updated UR refs, and UTR9a to 9b)
(odds and ends ... &fail considered harmful)
Line 675:
 
Overall, this example is not a very good use of these techniques.
 
== Odds and Ends ==
=== &fail considered harmful? ===
 
Okay, &fail is not the evil subversive scourge of programming that the GOTO was once (still is?). However, it is an oddity and while it survives (I presume) out of easy compatibility, I wonder about it's real worth.
 
In a recent discussion, someone expressed that &fail seemed like an anchor to the notion of languages that return Boolean values. And while that isn't quite how it works the appeal of that idea, especially to people new to the language, makes sense on some gut level. &fail is a throwback to an early version of Icon and it causes the current expression to fail. Yet, you will occasionally see it used like so:
<lang Icon>...
return &fail
end</lang>
 
In this usage it causes the return (not the procedure) to fail and fall through to the 'end'. Hitting end causes the procedure to fail.
 
Consider also,
<lang Icon>while .... }
if expr then return &fail
... other code ...
}
end</lang>
 
In this configuration the author might expect the procedure to fail; however, just the return does and the loop continues to execute.
 
What was probably intended was to use 'fail' which forces the procedure to fail:
Consider also,
<lang Icon>while .... }
if expr then fail
... other code ...
}
end</lang>
 
Now aside from some remote cases where the 'algebra' of alternation logic is made easier, or writing "(1 ~= 1)" is needed, I see little use for this construct.
 
= Run Time Considerations =
Anonymous user