Category talk:Unicon: Difference between revisions

Line 80:
== How to reasonably handle Icon .v. Union similarities and differences ==
 
=== At a high levelSummary ===
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.
 
The writeup of Icon and Unicon programs on Rosetta evolved from lone haphazard additions to a more structured approach. The rationale behind how this came to be is explained below. It is however partially constrained by the capabilities of the wiki and limitations of understanding of the wiki. It is also due to the fact that while the two languages are closely related; Unicon is mostly but not always a super-set of Icon. I hope we have finally arrived at a usable format. --[[User:Dgamey|Dgamey]] 15:40, 31 December 2010 (UTC)
I don't believe there is an ideal way to do this. Here are some of the considerations:
 
=== Template/ How to write up Icon and Unicon markup ===
* 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 [[:Category:Unimplemented_tasks_by_language]] or [[:Category:Unicon_examples_needing_attention]]. 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.'''''
 
There are several cases where Icon and Unicon are marked up differently:
=== Consistency and Eliminating Duplication ===
 
* the same code (or nearly the same code is usable with only minor differences requiring comment)
It's desirable to present all Icon and Unicon code consistently. This discussion was started to help achieve that goal. To that end, there are some objectives:
* there is a significant benefit to a Unicon only solution that requires a separate example
* Eliminate duplication
* there is no Icon solution
* Present the languages as closely related noting important differences
* Be able to easily tell when the code is Icon/Unicon
* Not confuse people new to the language
 
A template for the general case is shown below. It has the following characteristics (a) the listing in a task is concise and visibly shows that the solution is the same, (b) both languages are indexed by the header macro, (c) the Icon language template is used for keyword coloring, etc., (d) someone searching the page for either language will find them with a text search, (e) where pages/indices are split the code shows in the first half of the alphabet making it more accessible.
My initial attempt at this involved creating separate Icon and Unicon sections. Moving the code to the best fit. Often to Icon. Back/Forward referencing to/from the other section. This had several disadvantages including:
* separation of code
* inability to use the unimplemented tasks report or otherwise easily tell if the code was base Icon or exploited Unicon extensions
 
''Note: many examples in Rosetta use the second format as this general format arrived somewhat late on the scene. Eventually they will get converted.''
Next came realizations about how the wiki worked.
<pre><nowiki>
* Manual co-grouping would be subject to manual or (future) automated sorting resulting in confusion and inconsistency.
== {{header|Icon}} and {{header|Unicon}} ===
* Namely the <nowiki>{{header|language}}</nowiki> markup was responsible for registering completed tasks. The heading levels were not tied to this.
The following solution works in both Icon and Unicon.
* Using the unimplemented tasks report to track unicon extensions separately was potentially confusing to new *Icon programmers.
<lang Icon>procedure main()
# pure Icon code
...
end</lang>
 
Output:
==== How to write Icon and Unicon markup ====
 
sample output</nowiki></pre>
* Create a combined heading with indented sub-headings for each variant
 
* Create a both <nowiki>{{header|language}}</nowiki> markups. While this will register both tasks as done, it will likely be less confusing to the beginner.
The second case is where Icon and Unicon examples are significantly different. In this case the difference will be visually obvious in task indices.
Note: this was used as the general format from April 2010.
<pre><nowiki>
== Icon and Unicon ==
Line 120 ⟶ 116:
...
end</lang>
 
Output:
 
sample output
 
==={{header|Unicon}}===
<lang Unicon>procedure main()
The Icon solution works in Unicon.
# Unicon code
...
end</lang>
 
Output:
--- For core Icon/Unicon --- OR ---
 
sample output</nowiki></pre>
==={{header|Unicon}}===
The Icon solution works in Unicon. A solution that uses Unicon extensions has not been provided.
 
Similarly Unicon only solutions can be presented. However, in these cases uses the second format and a not implementable macro. ''This will keep the solution in the expected place in the task indices.''
--- For tasks that might benefit from a Unicon extension --- OR ---
 
=== Template / Other Useful Markup ===
==={{header|Unicon}}===
==== References to the Icon Programming Library ====
This solution uses Unicon extensions.
Use the following for IPL references. Note: if the IPL module solves the task, you should also include the critical code from the IPL so that a user of the site can see how the task was met without following offsite links. This isn't needed if the module is only incidental.
<lang Unicon>procedure main()
<pre><nowiki>
# extended Unicon code
[http://www.cs.arizona.edu/icon/library/src/procs/XXXX.icn fib provides YYYYY]
...
</nowiki></pre>
end</lang>
==== Unimplementable ====
</nowiki></pre>
Use one or both of these macros if the task cannot be implemented.
It is useful to briefly note minor differences.
<pre><nowiki>{{omit from|Icon}}
{{omit from|Unicon}}</nowiki></pre>
==== Needs improvement ====
The needs improvement tag can be used to mark possible improvements and give a reason.
<pre><nowiki>{{improve|Unicon|The example is correct; however, Unicon implemented additional graphical features and a better example may be possible.}}</nowiki></pre>
==== Works With ====
The works with macro provides standard text. '''Beyond that I'm not sure what advantage it has with regard to indexes or special pages?'''
<pre><nowiki>{{works with|Unicon}}</nowiki></pre>
 
=== Template for new tasks ===
For quick copy and paste.
The following quick copy and paste may be helpful creating new tasks.
<pre><nowiki>== Icon and Unicon ==
=== {{header|Icon}} and {{header|Unicon}} ===
<lang Icon>
</lang>
 
==={{header|Unicon}}===
<lang Unicon>
</lang>
The Icon solution works in Unicon.
{{libheader|Icon Programming Library}}
[http://www.cs.arizona.edu/icon/library/src/procs/XXXX.icn fib provides YYYYY]
 
{{works with|Unicon}}
</nowiki></pre>
 
Sample Output:
--[[User:Dgamey|Dgamey]] 02:21, 14 April 2010 (UTC)
...
 
{{libheader|Icon Programming Library}}
==== Discussion on how this evolved ====
[http://www.cs.arizona.edu/icon/library/src/procs/XXXX.icn fib provides YYYYY]
 
</nowiki></pre>
: May I suggest creating templates for these various references so that the wording can be adjusted uniformly if the need is felt? (Don't put the <nowiki>==...==</nowiki> in a template, though, because that breaks section editing's ability to pick out the right sections.) Also, insofar as Unicon is ''not'' actually Icon (I don't know either language so I can't judge this), for the second sort of cross-reference, use a header of the form ==[[Icon]]== instead because that will leave it on Icon's unimplemented list for people to work on as an Icon-only example. —[[User:Kevin Reid|Kevin Reid]] 11:22, 11 April 2010 (UTC)
::This is a good idea. I'm still not entirely happy with the way this works. I'd really like to be able to group Unicon and Icon side by side. But without doing something odd with the names the risk is that they would get moved at some point. --[[User:Dgamey|Dgamey]] 17:29, 11 April 2010 (UTC)
::: If the formatting and language/task recognition through <nowiki>{{header|somelanguage}}</nowiki> are separate this suggests a way to group the two languages together in a more satisfying and useful way. I'll post an update later. --[[User:Dgamey|Dgamey]] 02:31, 12 April 2010 (UTC)
:: As far as Unicon and Icon being different. Unicon provides some very significant extensions to Icon. There are also some niceties and syntactic sugar. A very few things behave differently (like random()). Having said that there are also a few things that won't directly move from Icon to Unicon. Probably 99% or more of Icon programs will run unmodified under Unicon. --[[User:Dgamey|Dgamey]] 17:29, 11 April 2010 (UTC)
 
=== When to have separate examples ===
Line 197 ⟶ 195:
return bar
end
</pre>
 
--[[User:Dgamey|Dgamey]] 02:21, 14 April 2010 (UTC)
 
=== Background / How this evolved ===
==== Similar languages and the wiki 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 [[:Category:Unimplemented_tasks_by_language]] or [[:Category:Unicon_examples_needing_attention]]. 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 ====
 
It's desirable to present all Icon and Unicon code consistently. This discussion was started to help achieve that goal. To that end, there are some objectives:
* Eliminate duplication
* Present the languages as closely related noting important differences
* Be able to easily tell when the code is Icon/Unicon
* Not confuse people new to the language
 
My initial attempt at this involved creating separate Icon and Unicon sections. Moving the code to the best fit. Often to Icon. Back/Forward referencing to/from the other section. This had several disadvantages including:
* separation of code
* inability to use the unimplemented tasks report or otherwise easily tell if the code was base Icon or exploited Unicon extensions
 
Next came realizations about how the wiki worked.
* Manual co-grouping would be subject to manual or (future) automated sorting resulting in confusion and inconsistency.
* Namely the <nowiki>{{header|language}}</nowiki> markup was responsible for registering completed tasks. The heading levels were not tied to this.
* Using the unimplemented tasks report to track unicon extensions separately was potentially confusing to new *Icon programmers.
 
===== Discussion on how this evolved =====
 
: May I suggest creating templates for these various references so that the wording can be adjusted uniformly if the need is felt? (Don't put the <nowiki>==...==</nowiki> in a template, though, because that breaks section editing's ability to pick out the right sections.) Also, insofar as Unicon is ''not'' actually Icon (I don't know either language so I can't judge this), for the second sort of cross-reference, use a header of the form ==[[Icon]]== instead because that will leave it on Icon's unimplemented list for people to work on as an Icon-only example. —[[User:Kevin Reid|Kevin Reid]] 11:22, 11 April 2010 (UTC)
::This is a good idea. I'm still not entirely happy with the way this works. I'd really like to be able to group Unicon and Icon side by side. But without doing something odd with the names the risk is that they would get moved at some point. --[[User:Dgamey|Dgamey]] 17:29, 11 April 2010 (UTC)
::: If the formatting and language/task recognition through <nowiki>{{header|somelanguage}}</nowiki> are separate this suggests a way to group the two languages together in a more satisfying and useful way. I'll post an update later. --[[User:Dgamey|Dgamey]] 02:31, 12 April 2010 (UTC)
:: As far as Unicon and Icon being different. Unicon provides some very significant extensions to Icon. There are also some niceties and syntactic sugar. A very few things behave differently (like random()). Having said that there are also a few things that won't directly move from Icon to Unicon. Probably 99% or more of Icon programs will run unmodified under Unicon. --[[User:Dgamey|Dgamey]] 17:29, 11 April 2010 (UTC)
 
== How to go about solving the tasks ==
Anonymous user