Anonymous user
Category talk:Unicon: Difference between revisions
m
moved background sections and guidance to end of page
m (→Stuff to Do: HELP WANTED) |
m (moved background sections and guidance to end of page) |
||
Line 1:
Note: This page is linked to from the [[:Category_talk:Icon]] page.
== How to go about solving the tasks ==
== Intent .v. Direction of tasks ==
There was an interesting discussion on [http://sourceforge.net/mailarchive/forum.php?forum_name=unicon-group the 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 [http://sourceforge.net/mailarchive/forum.php?thread_name=4BBDFF4D.9000505%40noao.edu&forum_name=unicon-group for this and other discussions]. The overall consensus is that '''we should show our best'''. --[[User:Dgamey|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? --[[User:Dgamey|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#Icon|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.'' [[User:MattOates|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.'' --[[User:Dgamey|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 [https://tapestry.tucson.az.us/twiki/bin/view/Main/StateNamesPuzzle | 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. --[[User:Dgamey|Dgamey]] 21:17, 8 April 2010 (UTC)
=== Constrained Tasks ===
I'm not sure how many of these there may be here. But using the [https://tapestry.tucson.az.us/twiki/bin/view/Main/LongestStringsPuzzle| 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 :) --[[User:Dgamey|Dgamey]] 21:17, 8 April 2010 (UTC)
= Stuff to Do =
== HELP Wanted ==
* Object oriented examples
* Graphics examples, particularly where we can show differences between Unicon and Icon
* Unicon Execution Monitoring examples, where they make sense
== Programming Tasks not Implemented ==
These will never end but [[Reports:Tasks_not_implemented_in_Icon|Icon - tasks not_implemented]] and [[Reports:Tasks_not_implemented_in_Unicon|Unicon - tasks not_implemented]] --[[User:Dgamey|Dgamey]] 03:10, 12 April 2010 (UTC)
== Easy Wins ==
I expect that many of these tasks are already coded in the Icon Programming Library or one of the Unicon packages. There are also example in the Icon and Unicon books. If you find an interesting task, check these sources first.
* [http://www.cs.arizona.edu/icon/library/pdx.htm The IPL permuted index of basic procedures]
* [http://www.cs.arizona.edu/icon/library/gpdx.htm The IPL permuted index of graphic procedures]
== Errors/Review Lists ==
See [[Template:Example-needs-review]] and [[Template:Incorrect]]. I'm not sure how you're supposed to know what is to be reviewed. Examples I've seen don;t have a lot of explanation.
Needs review doesn't seem to take an argument for formatting. Please add a brief note after the tag describing why. You can add more on the discussion/talk page if needed.
* Use <nowiki>{{improve|lang|Explanation}}</nowiki> for code improvement such as in
** <nowiki>{{improve|Unicon|The example is correct; however, Unicon implemented additional graphical features and a better example may be possible.}}</nowiki>
* Use <nowiki>{{example-needs-review|lang}}</nowiki> when the code may not meet the task description. Especially after a task description change.
* Use <nowiki>{{incorrect|lang|Explanation}}</nowiki> if the code doesn't meet the task.
There are a number of other related templates like improve that can be found [[:Category:Example_attention_templates]].
== The IPL and Uni Libraries ==
[[:Category:Solutions_by_Library]] need writing. Stubs have been created for:
* [[:Category:Icon_Programming_Library|The Icon Programming Library]] --> [http://www.cs.arizona.edu/icon/library/ IPL]
* [[:Category:Unicon_Code_Library|The Unicon Code Library]] --> [https://tapestry.tucson.az.us/unilib Unilib]
To reference these pages '''without inclusion''' on the library pages use these:
<pre>[[:Category:Icon_Programming_Library|The Icon Programming Library]]
[[:Category:Unicon_Code_Library|The Unicon Code Library]]</pre>
To reference library code and include the task page in the library use the [[Template:Libheader]]
<pre><nowiki>
{{libheader|Icon Programming Library}}
{{libheader|Unicon Code Library}}
</nowiki></pre>
Respectively these generate:
<nowiki><noinclude>{{libheader|Icon Programming Library}}</noinclude> and <noinclude>{{libheader|Unicon Code Library}}</noinclude></nowiki>
Notes:
* The Wiki automatically replaces spaces with underscores when constructing the link.
* Some pages in the Wiki have a 2nd parameter for libheader; however, it is not used.
== Unimplementable tasks ==
Mark tasks that aren't doable in Icon/Unicon as such. I believe there is an omit markup in curly braces, but I don't know much about it.
See [[:Category:Icon/Omit]] and [[:Category:Unicon/Omit]]
The syntax is <nowiki>{{omit from|language}}</nowiki>
* An example would be [[Address_of_a_variable|getting/setting the address of a variable]]
* Object oriented stuff in Icon
<pre><nowiki>{{omit from|Icon}}{{omit from|Unicon}}</nowiki></pre>
== Implementations ==
There are Category Pages for Implementations of other languages. There are certainly several variants that can be described for Icon including Jcon, MT Icon, IDOL, etc.
== Requesting Tasks ==
See [[Rosetta_Code:Village_Pump/Request_a_programming_task]]
= Stuff Done =
== Language Formatting ==
It turns out the <nowiki><lang blahblah></lang></nowiki> tags just provides syntax highlighting via something called GeSHi for syntax highlighting. Although there are Icon and Unicon tags on RC articles, there is GeSHi for either language. The details on AutoGeSHi are at http://rosettacode.org/geshi/ and maintained by user BenBE. (Thanks Mike) --[[User:Dgamey|Dgamey]] 03:10, 12 April 2010 (UTC)
* Thanks to [[User:MattOates|Matt Oates]] for getting these done --[[User:Dgamey|Dgamey]] 02:14, 20 April 2010 (UTC)
== Thanks ==
* [[User:SteveWampler]] for valuable insight into co-expressions
* [[User:MattOates|Matt Oates]] for work on the syntax coloring templates
* Clint for valuable insight into everything
* Art E, Andrew C
* Anyone else I forgot?
== How much to put in the language templates ==
Line 269 ⟶ 395:
::: 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)
| |||