Editing Icon (programming language) (section)

==Criticisms==
Laurence Tratt wrote a paper on Icon examining its real-world applications and pointing out a number of areas of concern. Among these were a number of practical decisions that derive from their origins in string processing but do not make as much sense in other areas.{{sfn|Tratt|2010|p=75}} Among them:

The decision to fail by default at the end of procedures makes sense in the context of generators, but less so in the case of general procedures. Returning to the example noted above, {{code|write(f(-1))}} will not output which may be expected. However:{{sfn|Tratt|2010|p=75}}
<syntaxhighlight lang="icon">
 x := 10
 (additional lines)
 x := f(-1)
 write(x)
</syntaxhighlight>
will result in 10 being printed. This sort of issue is not at all obvious as even in an interactive debugger all the code is invoked yet {{code|x}} never picks up the expected value. This could be dismissed as one of those "gotchas" that programmers have to be aware of in any language, but Tratt examined a variety of Icon programs and found that the vast majority of procedures are not generators. This means that Icon's default behaviour is only used by a tiny minority of its constructs, yet represents a major source of potential errors in all the others.{{sfn|Tratt|2010|p=75}}

Another issue is the lack of a Boolean data type{{efn|Although, as Tratt points out, K&R C also lacks an explicit Boolean type and uses 0 for false and any non-zero for true.{{sfn|Tratt|2010|p=75}}}} and conventional Boolean logic. While the success/fail system works in most cases where the ultimate goal is to check a value, this can still lead to some odd behaviour in seemingly simple code:{{sfn|Tratt|2010|p=76}}
<syntaxhighlight lang="icon">
 procedure main()
    if c then {
      write("taken")
    } 
 end
</syntaxhighlight>
This program will print "taken". The reason is that the test, {{code|c}}, does return a value; that value is {{code|&null}}, the default value for all otherwise uninitiated variables.{{sfn|Griswold|Griswold|2002|p=128}} {{code|&null}} is a valid value, so {{code|if c}} succeeds. To test this, one needs to make the test explicit, {{code|c {{=}}{{=}}{{=}} &null}}. Tratt supposed that it detracts from the self-documenting code, having supposed erroneously that it is testing "is c zero" or "does c exist".{{sfn|Tratt|2010|p=76}}