Category talk:Unicon

How to reasonably handle Icon .v. Union similarities and differences

Note: This page is linked to from the Category_talk:Icon page.

At a high level

The differences between Icon and Unicon programs can range the from obvious to very subtle. It can include entire paradigms, semantic differences, syntactic differences, and operational/behavior differences. A key challenge on Rosetta Code will be to fairly represent these without (a) duplicating everything and (b) under representing differences.

I don't believe there is an ideal way to do this. Here are some of the considerations:

• The wiki is only able to represent things a certain way and we need to work within the available framework
• Most of the programs entered under Unicon were more strictly Icon programs that also ran under Unicon
• There doesn't seem to be a useful way to have two very closely related languages:
  • Separate languages mean that contributors can take advantage of built in reports such as the or. Combining the two would loose some of this.
  • Placing the two together everywhere they appeared might work but would be at risk of being sorted either manually or automatically (in the future).
  • The two could be placed together if they had similar names, say Icon_(original) and Icon_(Unicon). We'd probably want a redirect as well from Icon and Unicon. However, I suspect there are places where the underlying naming will follow through. Otherwise if the links could be maintained alphabetically, then this might work. Feedback on this could be useful.

Consistency and Eliminating Duplication

The first step was a consistency update of the Unicon / Icon code. This put base code under Icon and referred from Unicon to Icon. This was accomplished by:

• Physically moving the code
• Changing the language tag from Unicon to Icon
• Referencing Unicon back to Icon

As seen below.

=={{header|Icon}}==
Some description
<lang Icon>procedure main()
...
end</lang>

...

=={{header|Unicon}}==
See [[#Icon|Icon]].

When to have separate examples

Next is the question of when to have a separate Unicon example?

• Clearly anything that makes use of a major extension should have a separate example. A simple example of this is HTTP - Icon .v. HTTP - Unicon.
• But what of simple syntactic sugar and conveniences? Certainly they should be shown, but if that's the only difference between the Icon and Unicon examples, I'm inclined to say no. Consider the examples below.
• Differences in program behavior are worth documenting. By way of example Loops/Break contains a note that describes how the Icon/Unicon random number generators differ in behavior.

A poor reason for both versions

Unless the task were parameter passing, type checking, and initialization the following would be a poor reason to have both versions.

#
#  Icon implementation of foo
#
procedure foo(i)  
local bar
i := integer(i)
bar := 0
....
return bar
end

and

#
#  Unicon implementation of foo
#
procedure foo(i:integer)  
local bar := 0
....
return bar
end

Quality and Style

There are a number of aspects of the sample programs that need improvement. These include:

• Commenting and documentation. Many of the examples (not just Icon/Unicon) have very little in the way of supporting comments, documentation, or description. There really should be a reasonable amount.
• Icon/Unicon-like .v. un-Icon/Unicon like code. A number of the examples are just bad translations of Basic or JavaScript. What should be done with these? Personally I think they should be replaced with examples that show how the language can be used. There may be a case for keeping them as an alternate version and calling out that it is a bad translation; however, given that this site is about showing off the essence of laguages - why would you do that?
• In a couple of cases there are links to IPL modules. Inevitably there will be more. How best to handle these? We could copy the code into a separate code box and call it out - but this could get repetitive. I believe that we should at a minimum place an off site link to the IPL web page for the code.
• What happens when there are multiple good examples of how to solve a task, such as on the Unicon Twiki (e.g. Names Problem or the longest string without using comparisons, math, or lists. Certainly we could talk about or refer to other solutions. But, should we show more than one?