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, Python, TCL, and J category pages were pointed out as good examples.

Category Page Language Box

I had a go at the main box. Unfortunately a lot of the terms aren't explicitly defined here.

• byte code compiled as I recall (way before Java made it popular)
• strong typing (This was Griswold's contention based not on declaration but the robustness of the operator framework) I think that this description of typing isn't as useful as it once was
• safe typing (based on robustness of the operator framework)
• implicit type expression

Here are the Type System descriptions Various programming paradigm tags can be added although there aren't some

• Concurrent programming may be a stretch for co-expressions
• Goal directed doesn't appear to be on the list and there doesn't seem to be a good fit
• Dynamic as a paradigm seems to mean scripting
• Object Oriented works for Unicon
• Procedural for both
• Reflective?
• Event driven may work for Unicon (I can't recall if it was experimental or included)

Does anyone know of Icon/Unicon BNF descriptions? The box can reference these and other languages do it.

--Dgamey 23:49, 8 April 2010 (UTC)

Language Comparison Table

A first stab at the LCT

• paradigms = procedural, object oriented, goal-directed (not defined and is this the same as logical programming)
• not standardized
• strongly typed
• safe types
• implicit
• what is typc
• nominative type compatibility
• dynamic type checking
• parameters by value? Not really. Mutable/Immutable.
• Garbage Collecting
• intended use .... a lot could be written here
• design goals .... comments from someone closer to the development would be better than mine Clint?

The Parameter_Passing page could use an update from a SNOBOL/Icon/Unicon specialist

--Dgamey 23:49, 8 April 2010 (UTC)

Other References

Wikipedia: Comparison of programming languages

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 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 {{header|language}} 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.

How to write Icon and Unicon markup

• Create a combined heading with indented sub-headings for each variant
• Create a both {{header|language}} markups. While this will register both tasks as done, it will likely be less confusing to the beginner.

== Icon and Unicon ==
==={{header|Icon}}===
<lang Icon>procedure main()
# pure Icon code
...
end</lang>

Output:

sample output

==={{header|Unicon}}===
This Icon solution works in Unicon. 

--- For core Icon/Unicon --- OR ---

==={{header|Unicon}}===
This Icon solution works in Unicon.  A solution that uses Unicon extensions has not been provided.

--- For tasks that might benefit from a Unicon extension --- OR ---

==={{header|Unicon}}===
This solution uses Unicon extensions.
<lang Unicon>procedure main()
# extended Unicon code
...
end</lang>

It is useful to briefly note minor differences.

For quick copy and paste.

== Icon and Unicon ==
==={{header|Icon}}===
==={{header|Unicon}}===
This Icon solution works in Unicon.

--Dgamey 02:21, 14 April 2010 (UTC)

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 ==...== 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. —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. --Dgamey 17:29, 11 April 2010 (UTC)

If the formatting and language/task recognition through {{header|somelanguage}} 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. --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. --Dgamey 17:29, 11 April 2010 (UTC)

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 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 for this and other discussions. The overall consensus is that we should show our best. --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)

Stuff to Do

Language Formatting

It turns out the <lang blahblah></lang> 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) --Dgamey 03:10, 12 April 2010 (UTC)

Programming Tasks not Implemented

These will never end but Icon - tasks not_implemented and Unicon - tasks not_implemented --Dgamey 03:10, 12 April 2010 (UTC)

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.

You could add text on the page - airing the dirty laundry or put it in the talk page.

Not sure if there are comments in the markup

IPL and Uni

Category:Solutions_by_Library need writing

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 {{omit from|language}}

• An example would be getting/setting the address of a variable
• Object oriented stuff in Icon

Requesting Tasks

See Rosetta_Code:Village_Pump/Request_a_programming_task