Category talk:Unicon

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

How much to put in the language templates

One question that comes to mind when thinking about Rosetta Code is how much to put into the language category pages?

It makes sense not to duplicate material in Wikipedia or on the language home pages. But it does make sense to provide enough information to readers to make useful comparisons.

While investigating this, the Oz, Ptyhon, TCL, and J category pages were pointed out as good examples.

Note: yet to build is the LCT (Language Comparison Table)

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

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

Intent .v. Direction of tasks

There was an interesting discussion on Unicon group forum] about meeting the intent .v. literacy in solving tasks. The Loops/Break task was used as a point of discussion.

The consensus seemed to be that we should be meeting the intent and not reading too much into the literal interpretation of the title. Unless there is specific direction within the task description we should have a free hand.

Thanks to Steve, Andrew, Clint, and Charles [1]] --Dgamey 21:17, 8 April 2010 (UTC)

Style

We should be aiming for programs that are Icon/Unicon like. Not just for translations from something like JavaScript or Basic.

• What should be done with if we find code that looks like a bad translation of something else or even something that could better represent Icon/Unicon. 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 languages - why would you do that? --Dgamey 21:17, 8 April 2010 (UTC)

Quality

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.
• 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. If the library function is the core of the solution (as in Input Loop then it should be included. But if the function is less important a reference should be sufficient.

I don't see it's necessary to give a copy of the IPL library function. To mention on the language page that the IPL exists and then link to the offsite code where applicable should be enough. Java has a huge standard library that is expected to be present with all implementations, as does C/C++ and many other languages. Task implementations gloss over the possibly hundreds of lines of library code all over Rossetacode, as this would be far too verbose and destroy the ability to make quick comparisons, more so with a large comment block for attribution. MattOates 07:34, 7 April 2010 (UTC)

Fair enough I wasn't sure what the overall convention was here. In this case where the main program does almost nothing and the IPL procedure does all the heavy lifting something more seemed to be needed. Perhaps a note and brief description. Or perhaps just the link. --Dgamey 21:17, 8 April 2010 (UTC)

Multiple Solutions

What happens when there are multiple good examples of how to solve a task with different approaches? Should we show more than one?

By way of example, on the | Unicon Twiki - States Names Problem there are at least two different approaches to the problem. If we were to hit one of those here what to do?

Certainly we could talk about or refer to other solutions. But, should we show more than one? My take is that it's not unreasonable to show a couple of good alternate approaches in the same language. Just don't flood the reader. --Dgamey 21:17, 8 April 2010 (UTC)

Constrained Tasks

I'm not sure how many of these there may be here. But using the Unicon Twiki - Find the longest string problem without using comparisons, math, or lists as an example, perhaps we should introduce a few. I'd like to see how some of the more traditional languages do this :) --Dgamey 21:17, 8 April 2010 (UTC)