Revision as of 20:26, 8 July 2012

Summary

What are, or should be, the Rosetta Code conventions for dialects of programming languages - implementations on specific platforms that may have minor differences of syntax and functionality from the official distributions?

Discussion

I would rather have different dialects not count as language of their own. Otherwise we have many main languages, which are similar in many ways, and many more items to show the code for. The navigation gets cluttered up and language lists would need to be structured in a hierarchy. This is already a problem with ZX80 Basic and C64 Basic and maybe more variants.

I propose

have an entry page for the dialect which redirects to the main language
allow different, dialect specific implementations of the same problem on the page of the "main" language.

Codecop 13:33, 28 January 2012 (UTC)

My general position has been to leave the distinction to the language community. To a C++ programmer, all BASIC implementations might look alike, but to people with production code in QuickBasic, that's a nonsensical position. --Michael Mol 14:44, 28 January 2012 (UTC)

I tend to agree, it will be very specific to the language and community. Guidance and suggestions are probably welcome and this would be a good anchor page, but I would not want to weigh in on any of the languages mentioned above. --Dgamey 14:51, 28 January 2012 (UTC)

One man's dialect is another's version. To a beginner reading these pages, it gets confusing enough to have to know a priori what the differences/defaults/nuances are and what can or can't be used in their version/release/sub-release/dialect/whatever.

I'm going to read into the proposal that navigation is really the issue and not pure numbers. If we worry about pure numbers, we have about 600 tasks and 450 languages which results in a pretty big matrix. Not that we will ever see that as other than a sparse-ish matrix. When that happens we will need to solve that problem. Until then I have to fall back onto YAGNI. I suggest we put some practical examples and suggestions/ideas here. Then when a community starts to have a problem they have a place to come for ideas. --Dgamey 15:03, 28 January 2012 (UTC)

Examples

Icon and Unicon

Hi, I did a lot of the work on Icon and Unicon which are closely related. Much of what I went through is discussed on the talk pages for Category_talk:Unicon. What you are proposing isn't far from what I did. Here's a summary, you can also see how it looks (there's over 450 examples on RC):

Each distinct variant gets it's own page/category. If there are minor variants, it may make sense to put them in a section of the major variant's page.
In tasks, I have one header with both major variant names in a single header line. Both Icon/Unicon were used because of recognition and to prevent orphaned headings (This may become more problematic as there is also a Jcon and ObjectIcon). Orphaned headings and duplicate efforts is a big problem if you have more than a few contributors. I found that having a combined header that sorts early worked best.

At one point I had thought of disambiguation pages as a possible part of the solution but I concluded I didn't really need them and they didn't add much in this case. That may not be true with a large number of true variants and also like named but unrelated languages (think Basic and VisualBasic).

Under the task heading there is a structure that allows different solutions where there are differences. However, where the differences are very minor I usually rely upon description text.

I tried a couple of kicks at it and found this approach practical (not necessarily perfect). It may or may not work with others. Hope this helps.

--Dgamey 14:42, 28 January 2012 (UTC)

UNIX Shell

Today:

Category:UNIX Shell counts as one language and contains all Bourne-compatible dialects, including Almquist Shell, Bash, Bourne Shell, Korn Shell and Z Shell.
Category:Bash and Category:Korn Shell redirect to UNIX Shell.
Category:Zsh (Z Shell) is not empty. When it becomes empty, it can redirect to UNIX Shell.
Category:C Shell and Category:es (Extensible Shell) count as two more languages, because these shell dialects are too different. For task pages, these languages appear as subsections of UNIX Shell.
- So Loops/Infinite#UNIX Shell lists C Shell and es under UNIX Shell.
Sieve of Eratosthenes#Bash is a dummy section that links to Sieve of Eratosthenes#UNIX Shell. This stops editors who want to write a Sieve of Eratosthenes in Bash.

--Kernigh 16:12, 28 January 2012 (UTC)

REXX, ooRexx, and others

Nowadays there are many implementations of Rexx.

As 'my' two Rexxes are currently TSO-Rexx (still Classic Rexx to me)
and ooRexx I shall enumerate the incompatibilities between these two.

Rexx was created some 30 years ago for VM/CMS and was later ported
to MVS/TSO. Its current grandchild for Windows and other PC-platforms
is ooRexx.

Some 'features' of the original Rexx were removed
- Use of @#$¢ as or in symbols
- a= as a short form of a=''
- Multi-line strings (extending a string over line boundaries'
- stream I/O (present in CMS but only optional on TSO (not on 'mine')
  (on TSO I have to use EXECIO)
- Bifs: externals, find, index, justify, linesize
- the Upper instruction
- /= and /== as alternatives to \= or \== (see characters below)

Other features were introduced with the ANSII standard created
by a committee comprising Rexx implementers from IBM (notably the
original author, Mike Cowlishaw) and elsewhere:

- Date and Time conversion
- Parse Caseless
- Address With (not available in ooRexx)
- Bifs changestr, countstr, qualify

A feature introduced with ooRexx (and Regina unless you opt out):

- -- as line comment (instead of /* ... */)

Avoiding all of the language elements mentioned above makes a program
portable across the two Rexxes I am using and therefore interested in.
Using additional features introduced with other implementations
(notably directives in ooRexx) will also prohibit program porting.

Characters:
Originally ¬ was defines as not-character and /= was accepted for not equal.
This was later changed to the backslash and ^ on the host.

On my German TSO I cannot use | and \ due to code page differences.
My Rexx sources on TSO use therefore ! and ^, respectively.
(I avoid the ^ by using lt-gt instead of ^=)

For a Brief History of Rexx see
http://www.speleotrove.com/rexxhist/rexxhistory.html
For a rather complete list of Rexx implementations see
http://www.speleotrove.com/rexxhist/rexxplat.html
(both courtesy Mike Cowlishaw)

--Walterpachl 20:23, 8 July 2012 (UTC)