Talk:Icon (programming language)

This is the talk page for discussing improvements to the Icon (programming language) article.
This is not a forum for general discussion of the subject of the article.

Put new text under old text. Click here to start a new topic.
New to Wikipedia? Welcome! Learn to edit; get help.

Article policies

Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL

regular expressions

Just for historical purposes..

One of the frequent requests in the old Icon mailing list for Icon was adding regular expression support to the language. Unfortunately, I'm not sure who responded, but the best comeback to one of these requests was:

Asking for regular expressions in Icon is like asking for training wheels for a Harley

CheyenneWills 16:40, 29 September 2006 (UTC)[reply]

lists and tables

most modern scripting languages combine lists and tables into a single feature

I'm not aware of any evidence to support this claim.

In fact, I have never seen this ! To take the most well-known, Perl, Python, Ruby don't do this ! 213.244.14.206 14:56, 19 June 2007 (UTC)[reply]

The article was updated and text, objected to, removed a long time ago by Jibal here: [Difference between revisions from 7/20/2007 to 8/6/2007]. I have never closed or archived a talk discussion before, guessing archive is the next step, waiting on advice or intervention by more experienced editor before preceding. Thank you. Ronaldws (talk) 22:38, 20 August 2022 (UTC)[reply]

There is a lot of ancient moot commentary on talk pages ... no need to close or archive it. Your comment is enough to alert editors that the text was removed (which I presumably did upon reading this comment 15 years ago).

Later comments here note that there are other scripting languages that do this, but the claim that "most modern scripting languages" do seems excessive, needs a reliable source else it is original research, and simply isn't necessary in an article about Icon. Jibal (talk) 22:59, 21 August 2022 (UTC)[reply]

Lua does this, but I can't think of any others that do. 72.146.170.188 (talk) 20:25, 4 August 2008 (UTC)[reply]

REXX does this as well. REXX's stem variables are used to handle both associative arrays (tables) and lists (numerical indexed arrays). The underlying implementation just treats them as the same type of "object" and the whole concept of using stem variables to handle lists is just an accepted common REXX programming convention. CheyenneWills (talk) 16:39, 26 September 2008 (UTC)[reply]

My understanding is that arrays in PHP scripts, arrays in bash scripts, and arrays in JavaScript can be used as both associative arrays and numerical indexed arrays. (Although "Some people think that you shouldn't use [a JavaScript] array as an associative array."[1]). Do you merely not know this, or are you trying to crack a joke implying that bash, JavaScript, and PHP are not "modern scripting languages"? Would the talk page for associative array#Language support be a better place for this discussion? --DavidCary (talk) 15:10, 19 December 2014 (UTC)[reply]

license

Do anybody know what is the license on Icon implementation and IPL? I have found no trace of license on their website. 83.246.135.39 (talk) 10:49, 31 October 2009 (UTC)[reply]

The base source of Icon is in the public domain (as per the README file in the source tar file). Included with the base source are two sub-directories that have some licensed code, one from Microsoft in the wincap directory, the other is a copy of XPM, which is copyrighted by GROUPE BULL. Both licenses are basically AS-IS licenses, allowing redistribution of the source. Both sets of sources are only utilized if creating the graphics version of Icon. Within the Icon Program Library, most of the source is public domain, there are a few source files that are copyrighted, or have included copyrighted code. CheyenneWills (talk) 00:59, 3 November 2009 (UTC)[reply]

The search example is a bit unfair about the verbosity of other languages. The example could be written as

 char *s = "All the world's a stage. And all the men and women merely players";
 int i = 0;
 while ( -1 != ( i = indexOf("the",s,i)) )    write(i++);

— Preceding unsigned comment added by 82.14.176.247 (talk) 09:51, 21 April 2013 (UTC)[reply]

other icon programming languages

I see that visual programming language and de: iCon-L mention a programming language with a similar-sounding name. Does this article need a wp: hatnote to help readers who end up here while looking for that other programming language? --DavidCary (talk) 15:16, 19 December 2014 (UTC)[reply]

The visual programming language really refers to possible confusion with a graphical icon described by the wikipedia article Icon (computing). The de: iCon-L software product and graphical programming system still exists today, over 7 years later, does not seem to be going away and the web site of the company has pages for the product in English. A disambiguation page appears to make sense ... perhaps something like (two proposals but preferring the first):

Ronaldws (talk) 23:01, 21 August 2022 (UTC)[reply]

icon syntax highlighting lost

Since the switch from Geshi to Pygments for syntax highlighting (phab:T85794), support for 'icon' and 'unicon' was unfortunately dropped, as can be seen with the plain text formatting on this page and many others like Unicon (programming language) and Generator_(computer programming). If you want specialised syntax highlight support again, it will need to be added to Pygments. However we could also add a compatibility fallback, e.g. to 'pascal' which works quite well for highlighting these languages. John Vandenberg ^(chat) 12:57, 14 July 2015 (UTC)[reply]

Criticism section

Some of the "Criticism" section feels opinion.

The linked paper that is the basis for the criticism section is a reference to the experiences in developing a new language (Converge) that was derived as a cross between Icon and python.

Some of the design considerations of Icon were derived from Snobol, where the concept of success/failure instead of boolean is one of primary features of that language. Icon, like Snobol, does require a different way of "thinking" because of the use of success/failure instead of using booleans. To a Snobol programmer, this behavior of Icon does feel "natural".

As with many programming languages there can be nuances that can trip up a programmer, especially if the language has concepts that are radically different from other programming languages. Because there are some radical differences, there are typically idiomatic ways of performing certain operations. The similarity of syntax with other languages can further lead to confusion since there might be an expectation of common behavior. To give an example, C's uses and idiom of 0 as "false" and everything else as "true", while Icon's idiom is to use a conditional expression to check the value that you want. This is not saying that C is wrong and Icon is correct, it's just that they are different. In some languages (e.g. pascal) there is a boolean data type and using an non-boolean variable as a raw check for true/false produces a compile time syntax error.

The design choice of success/failure is documented in the introduction to Icon and as well as being covered in the 1st chapter of Icon Programming Language book. The points brought up in the criticism are covered the topic 'Success and Failure' in the Icon Programming Language book has notes of caution when using Icon due to the differences with success/failure and boolean logic (e.g. the fact that failure is inherited by the assignment operator, and that use of conditional expressions).

To rework the specific examples given in a more "Iconic" fashion:

 x := 10
 ...
 x := f(-1) | &null     # if f fails, assign a default value
 write("f(-1) is ", \x | "undefined")

 if /c then {           # Use a conditional expression to check to see if c is &null
     write("taken")
 }

It should also be noted that the 2nd example given was misquoted from the original article. In the article, the example firsts sets c to 10 (c := 10) then performs the test, this is followed by removing the assignment and repeating the test. The default value of an initialized variable is &null not zero

CheyenneWills (talk) 22:51, 22 June 2021 (UTC)[reply]

hmm

A lot of the examples on the evaluation differences are wrong. For ex. it works the same way with while (var=readLine()) write(var); in at least C and PHP, no need to check for null manually or catch exceptions. It will return with empty/falsey value when done.

Also for most statements such as IF’s you can do stuff like:

if ($var = fnCall() && …)

since it’s a boolean test it will get implicitly cast as that right after the assignment… I probably failed to articulate that right, but my point is you get the value in the variable and the test can still fail and short circuit

The paper called it backtracking in another example where I’d just say the expression was aborted/cancelled before the assignment was done… just seems heavy with exaggerations when almost all I’ve seen work pretty much the same in any language.

Ok maybe not aborting an assignment - but then again… I haven’t checked if this works, but should give the same result in for example javascript as if you never defined the var at all:

var = booleanCheck() ? value : undefined; 81.235.181.45 (talk) 06:07, 27 February 2022 (UTC)[reply]

"It works the same way with " while (var=readLine()) write(var); "in at least C and PHP" ... Perl apparently needs magic suggesting an advantage for the success / failure model. An example of the problem that chokes Perl is a text file that ends with "prev text\nlastish line\n0" so that the very last line just has the numeral 0 with no trailing newline. When Perl evaluates the string "0" it evaluates to false so as documented in a few places including, "Learning Perl", R Schwartz, T Phoenix https://docstore.mik.ua/orelly/perl3/lperl/ch06_01.htm, Perl magically adds a defined test to code like while (<STDIN>) { ...}. In PHP the example from PHP.net works correctly while (($line = fgets($handle)) !== false) { ... } but while ($line = fgets($handle)) { ... } fails similarly to Perl.

The short circuit evaluation misses the point of the paragraph which is trying to show an example of data backtracking to provide atomicity, and so the point is about undoing the assignment of variable i := 10 back to the value of i before the block. The article does not appear to discuss control backtracking which could be todo, possibly after the section on Generators. The example in the Wikipedia article shows data backtracking and forgets some modified data in the block whereas control backtracking may move back execution of the program within an expression (maybe block?), for example to generate a "next" value from an earlier generator before moving ahead to iterate through subsequent generators.

Ronaldws (talk) 00:53, 16 August 2022 (UTC)[reply]

Perl magically adds a defined test to code like while (<STDIN>) { ...}.

FWIW, it didn't in early versions. I pointed out the case that fails on a Perl usenet group and Larry Wall responded by adding the hacky defined test to while (<...>)

Since you appear to be knowledgeable about Icon, it would be nice if you could fix some of the issues in the article. Jibal (talk) 23:08, 21 August 2022 (UTC)[reply]

"if the operations to the right evaluate to true" confusing ... perhaps better "if the conditional evaluates to a true value"

Above code block write(a < b) in section: Goal-directed_execution

"if the operations to the right" ... Icon programming class from U of Arizona many years ago and rusty but bold part of quote confusing. Likely, based on textbook, better written "if the conditional evaluates to a true value". Likewise: "if the operations to the right succeed" maybe better written "if the conditional evaluation is successful and does not fail". Ronaldws (talk) 00:59, 12 August 2022 (UTC)[reply]

Sounds right ... WP:bebold and go ahead and make such improvements. Jibal (talk) 23:11, 21 August 2022 (UTC)[reply]

Tried putting in this update and #other_icon_programming_languages. Ronaldws (talk) 01:30, 26 August 2022 (UTC)[reply]

Actively Incorrect description of Icon's execution mechanism

Icon is badly misrepresented here. Details follow.

Throughout "returns" is used to incorrectly describe Icon's expression evaluation mechanism. Specific instances (hopefully all instances) will be noted below with explanation of why they are actively wrong and misleading. Some general specifics are as follows.

Failure and Success are NOT values in Icon, they are eventualities. &fail is NOT a value but is treated like one. Procedures that use suspend are not called again to get the next generated value. There is one call to get those as needed in the expression from which the call is made. Calling such a procedure again produces its generator sequence a second time, NOT the second element of its generator sequence. So the calling mechanism has been entirely wrongly stated as if coded in e.g. Python.

The misleading impression is given, via these specific mechanisms of wrong explanation and similar, that Icon is more like other programming languages in its execution mechanism than is actually so. The article in this way strongly misrepresents Icon, making it seem more mundane, more like other imperative languages.

This is a very badly written article overall, far too long and not explaining Icon's uniqueness in a direct simple and clear way, but in fact obfuscating this and doing so by actively misstating how Icon works. The standard of writing is poor too, but I omit criticizing that here too so as not to overload this note. It would be better to replace the entire article. Still, here are some specific falsehoods paragraph by paragraph.

Para.1

"Icon is a very high-level programming language based on the concept of "goal-directed execution" in which an expression in code returns "success" along with a result, or a "failure", indicating that there is no valid result."

Misleading:

0. The actual term is "goal-directed evaluation", see below for specifics.

1. Expressions don't "return" anything! The word "return" has a wide meaning in programming as terminating a function or procedure call and sending back a resulting value. Expressions "evaluate to" something. They don't return. Using "return" in this article in this sloppy nebulous way is confusing given that standard meaning of "return". It evokes misleading connotations about Icon.

2. Every expression in Icon is a generator, i.e. defines a sequence of potential results. Expressions in Icon don't "return" (sic) anything when evaluated except at least one possible value or no value, corresponding to defining a generator sequence with one or more values or an empty generator sequence: one with no values. The first is called success the second failure. The description makes expression evaluation in Icon sound like calling a function in Go with a second return channel for errors. Not so. Not only does an expression not "return" in Icon, it also does not return Success or Failure. They are not values, but in fact an interpretation of whether or not the generator sequence that an Icon expression denotes is non-empty or empty. Note that how Icon is implemented is irrelevant here. We are discussing Icon in and of itself.

3. Makes it sound as if "goal-directed execution" is just the success/failure mechanism, and makes it sound like "goal-directed execution" is the overarching basis of Icon, whereas it is a side effect of the generator-based evaluation mechanism of all expressions in Icon which is completely obfuscated by the falsehoods asserted about generators later on. And everything in Icon is either a declaration or an expression. So evaluating expressions is the entirety of execution in Icon. For this reason "goal-directed evaluation" is the correct term. More on the last below.

Para.4

"[Icon] also inspired other languages, with its simple generators being especially influential; Icon's generators were a major inspiration for the Python language."

1. Python abandoned Icon's simple generators upon its inception excepting in one form: functions that yield, and even there explicit conventional iteration is needed to generate anything. Icon's implicit generator expression evaluation mechanism is completely absent. Icon's simplicity in this regard is not present. So very misleading text. Icon inspired putting yield in Python would be more like it.

Moving on to the next section.

Goal-directed execution

I won't criticize the SNOBOL descriptions, though they need it for similar reasons.

Para.4

"The second was to allow "failure" to be passed along the call chain so that entire blocks will succeed or fail as a whole."

1. This occurs at the granularity of expression evaluation. The specific statement above suggests that the failure of a call causes the failure of the caller which in general is false. It is nebulous talk, not a statement of how Icon works. It is the propagation of failure from subexpressions of Icon expressions according to the rules of generator expression evaluation that characterizes Icon. Even this statement is nebulous and need to be qualified.

Para.5

"In contrast, in Icon the read() function returns a line of text or &fail."

1. No it does NOT. &fail is NOT a value. The mechanism is completely misrepresented.

"Because success and failure are passed up through the call chain,"

2. Only when calls are nested or when code is written to deliberately effect this. And this mechanism described properly is not even about the business of calling procedures. So an obfuscating frame of reference too.

"if performs the then block if its "test" returns a value, and performs the else block or moves to the next line if it returns &fail."

3. No. &fail is not a value. Misleading. Should say "if it fails" which describes the evaluation mechanism properly.

"Icon refers to this concept as goal-directed execution.[23]"

4. No, Icon refers to it as goal-directed evaluation --- check the reference at the end of this sentence!

5. No, this is not the concept of goal-directed evaluation. The sentence has completely muddied the waters of what goal-directed evaluation is. Again, check the reference.

Para.6

"For instance, if the file being read does not exist, read fails without a special situation being indicated."

1. This is false. It is opening the file that fails. If some value is passed to read that is not a file (an Icon value representing a file produced by a call to open) then a run-time error ensues.

Para.7

"A key aspect of goal-directed execution is that the program may have to rewind to an earlier state if a procedure fails, a task known as backtracking."

1. Saying "the program" suggests this needs to be coded up! No, execution may have to implicitly rewind to an earlier state without explicit direction by the programmer.

Generators

Para.1

"Icon also includes the concept of procedures that do not immediately return success or failure, and instead return new values every time they are called."

1. Utterly and completely false and wrong in several ways enumerated here. It's as if the author(s) don't know anything about the Icon language. Details in the following points.

2. Success and failure are not returned, they are attributes of the generator sequence defined by the call. That sequence is either empty or not, and failure means the first, success means the second.

3. All calls have a generator sequence. It's just that some define sequences of length at most one. The "immediately return success or failure" nonsense presumably refers to these.

4. The procedures spoken of are those that suspend values instead of fail or return. They do NOT work like that! Clearly the author of this text is NOT qualified to write about Icon and has failed to understand the execution mechanism of Icon entirely which is the whole point of the language and is completely nonstandard. Such a procedure call defines a generator sequence like any other expression and it is called ONCE to generate that sequence automatically as needed by the expression the call is a part of.

Para.2

"A procedure that lacks any of these keywords returns &fail, which occurs whenever execution runs to the end of a procedure"

1. &fail is NOT a value. Writing &fail in Icon defines the empty generator sequence, i.e. it fails. No value there. Should just say "fails" instead of "returns &fail".

"Calling f(5) will return 1, but calling f(-1) will return &fail."

2. Same problem.

"This can lead to non-obvious behavior, for instance, write(f(-1)) will output nothing because f fails and suspends operation of write."

3. Obvious to the Icon programmer, one who understands the simple rules of the evaluation mechanism. Only non-obvious if you expect Icon to be like other languages, an impression the authors are obfuscating into existence.

4. Evaluating f(-1) fails propagating to write failing. "Suspend" is nonsense.

Para.3

"Converting a procedure to be a generator uses the suspend keyword, which means "return this value, and when called again, start execution at this point". "

1. FALSE. As stated above, there is no "called again". The entire generator sequence is made available at the point of call with a single call.

"In this respect it is something like a combination of the static concept in C and return."

2. No, it is NOT, for several reasons including 1. Another is that several calls of the same procedure may be active having generated only part of the generator sequences they define ready to be resumed, but they do not interfere with one another. A C static variable allows only one use of the sequence generated at a time, and has to be explicitly called again, exactly how Icon DOES NOT. The authors don't understand Icon.

"creates a generator that returns a series of numbers starting at i and ending a j, and then returns &fail after that."

3. Misleading. Generators in Icon don't return things. This text written as if the procedure is called repeatedly to return from each call the next element of the generator sequence defined by a call of ItoJ which then upon the last such call fails (described wrongly as returning &fail). This text is written entirely in the bogus frame in which generators have to be explicitly iterated through which is entirely wrong in Icon.

"When another call is made to the same function, execution picks up at that point with the previous values. In this case, that causes it to perform i +:= 1, loop back to the start of the while block, and then return the next value and suspend again. This continues until i <= j fails, at which point it exits the block and calls fail. This allows iterators to be constructed with ease."

4. BOGUS. Unrelated to how Icon works. There IS NO OTHER CALL. If another call was made it would define the same generator sequence all over again. A single call makes the entire generator sequence available at the point of call as needed. Icon doesn't work like a conventional language!

"at which point it exits the block and calls fail"

5. No, fail means return only with no value (i.e. the rest of the generator sequence defined by the call is the empty generator sequence).

A lot of bad writing follows. It is "alternation" that is a way to build generators as per writing about Icon. Not "the alternator" and the explanation of its evaluation is given no underlying justification, i.e. given no basis. If the Icon evaluation mechanism was simply explained first, such things could be made clear as special ways that this mechanism can be used. Instead no explanation of the evaluation mechanism is made in the entire article. Icon is treated as if it has the usual kinds of control flow and execution with special case mechanisms for failure instead of Boolean testing. This is unrelated to how Icon actually works.

I can't list all the nonsense in what follows, so I'll stick to the highlights.

Para.6

"Internally, the alternator is not simply an or and one can also use it to construct arbitrary lists of values."

1. Saying "lists" is misleading in the context of programming where it connotes a list data structure and there is no static structure, no stored structure here at all. Once again expressions-define-generator-sequences in Icon has been not noticed by the authors. This defines a generator sequence.

2. Internally?? It is a part of the language definition and evaluation mechanism, not a hidden feature! Once again, the generator nature of evaluating all expressions has been obfuscated in favor of pretending it is ordinary evaluation with frills for failure.

"Icon is not strongly typed, so the alternator lists"

3. Generator sequences NOT lists. As stated above.

Para.7

"This code calls ItoJ and returns an initial value of 0 which is assigned to x. It then performs the right-hand side of the conjunction, and since x % 2 does equal 0, it writes out the value. It then calls the ItoJ generator again which assigns 1 to x, which fails the right-hand-side and prints nothing. The result is a list of every even integer from 0 to 10."

1. Generators are not "called". ItoJ is a procedure called once here. That call is suspended each time an element of the generator sequence it defines is obtained is /resumed/ automatically to get further elements of the generator sequence the call defines.

Para.13

"The every operator is similar to while, looping through every item returned by a generator and exiting on failure"

1. Confusing `every` with `while` is a perennial problem for new Icon programmers.

2. Generators do not return values; `every` iterates through all of the generator sequence defined by the expression to its right.

All the special case talk with no statement about the evaluation mechanism in Icon gives the misleading impression that Icon is needlessly complicated. What is complicated here is the impression of Icon that the authors possess, a largely incorrect one at that, given the many falsehood uttered here. Icon itself is a remarkably simple system for dealing with generators algebraically rather than through explicit imperative constructs. None of this is revealed here, which could be done with half the text. The authors do not understand the language!

There is more wrong in intervening sections, but I now skip forward the worst excesses in the following section.

String Scanning

Para.4

"pos returns the current value of &pos."

1. FALSE: pos does NOT return the current value of &pos

"It may not be immediately obvious why one would need this function and not simply use the value of &pos directly; the reason is that &pos is a variable and thus cannot take on the value &fail, which the procedure pos can."

2. &fail is NOT a value so this is nonsense.

3. pos is a function (built-ins in Icon are called functions, user written are procedures)

4. pos cannot take on a value. It can be called and fail.

5. A variable can fail in Icon. For example the variable &fail itself fails to produce a value.

"Thus pos provides a lightweight wrapper on &pos that allows Icon's goal-directed flow control to be easily used without having to provide hand-written Boolean tests against &pos."

6. Bogus reasoning led to here, so this makes no sense as a consequence of such.

"If it is not zero, pos returns &fail, which is inverted with the not and the loop continues."

7. &fail is not a value and inversion is unexplained: there are no Booleans so what does it mean here? Explaining would have to involve actually speaking of Icon's evaluation mechanism so this confusing nebulosity is the result. It gives the impression the authors don't understand it, which may well be true. They just say "inversion" and don't get inside the box.

Criticisms

This section is entirely junk. It amounts to various persons not realizing there is a simply stated evaluation mechanism in Icon that is ubiquitous and needs to be understood in order to read and write code. The complaints are tantamount to "because I don't understand Icon's elegant generator based evaluation mechanism then I misread simple Icon programs". Because the article doesn't explain that mechanism in a couple of paragraphs, this is non-obvious. Again it comes from the tacit expectation, including by the articles authors, that Icon is essentially like other languages with eager localized execution. It is not. In fact the evaluation mechanism is a kind of lazy evaluation inside each bounded expression. None of this is explained by the article. Those using Icon do not find those behaviors wrong.

Conclusion: The article is almost irredeemable. Editing it into something correct and fit for purpose would be much harder than just writing it properly in the first place, and would make it perhaps half the length and enormously more intelligible. ~2025-42265-75 (talk) 21:55, 21 December 2025 (UTC)[reply]