Category talk:OoRexx

Plagiarism

In that the code presented herein is covered by the GNU Free Documentation Licence 1.2, I'm not convinced that anything developed or reimplemented from an example in another language can be or should be identified as "plagiarized", particularly if the appropriate acknowledgements are in place. (Rosetta Code even provides the means witihin the editor to indicate that a program is a direct translation of some other work via the {{trans|XXXX}} template. [see Template:Trans]) Plagiarism can be a very emotive word and a serious charge to level at someone, particularly when related to software development; we should avoid describing work presented here as such.

Remember that by contributing programs to Rosetta Code you are "promising us that you wrote this yourself, or copied it from a public domain or similar free resource" [sic.] --Alansam

Pls advise at a better (acceptable) wording! I did to the best of my knowledge. --Walterpachl 08:30, 9 June 2012 (UTC)

Hi Walterpachl; You should say that the second was an adaptation of the first example that works on the IBM ...

In general, the two paragraphs should be changed so that there is no need for the correction mentioned at the beginning of the second paragraph, just remove the wrong info on compatibility between Rexx and ooRexx. --Paddy3118 08:54, 9 June 2012 (UTC)

thanks. changed. --Walterpachl

The first paragraph still states that Since ooRexx is fully compatible with REXX, every ... is incorrect. ooRexx is not fully compatible. -- Gerard Schildberger 17:03, 10 June 2012 (UTC)

It was mentioned that the REXX example for the 24 game was adapted (changed?) to run on IBM's Rexx (presumbably TSO's version). What exactly was changed to do this? What code in the original example is incompatible with IBM's version? If this can be enumerated, than I could go back and change all the other REXX examples to make them all IBM REXX compliant. -- Gerard Schildberger 17:03, 10 June 2012 (UTC)

I cannot use backslash and vertical bar on my (German) TSO

That's why I avoid the backslash (using <> instead of \=) and have still to exchange | and ! when up/downloading code. The only other thing I changed was L.= to L.= and the like This not for the host's sake but for ooRexx' The host accepts it: 6 *-* a= 7 *-* Say '>'a'<'

 >>>   "><"

--Walterpachl 08:30, 11 June 2012 (UTC)

Yes, I forgot that the CMS and TSO REXXes aren't ANSI compliant. The backslash (\) is supposed to be accepted as an alternative to the not (⌐) character, but apparently nobody in IBM land is inclined to change it. Now, the IBM and CMS versions do accept the forward slash (/) so you can specify j/==qqq for instance, but Regina refuses to honor that version (the forward slash). PC/REXX, R4, and ROO do support the forward slash in comparisons. So right now, there is no way to make a Regina REXX (source) program completely portable (to IBM mainframes) when you want to use a not symbol in a comparison. Of course, you could use compound IF-THEN-NOP-ELSE type construct. -- Gerard Schildberger 08:46, 11 June 2012 (UTC)

I should also mention that Regina REXX doesn't honor the not (⌐) symbol, but PC/REXX, R4, and ROO do. I would like to know if NetRexx, ooRexx, CRX, AREXX, BREXX, and others support that characger. Perhaps if someone could chime in who know those interpreters. -- Gerard Schildberger 08:52, 11 June 2012 (UTC)

Coloring / Highlighting Rexx code

I asked for adding GeShi highlighting for Rexx (and ooRexx) code. This is now in place. Thanks are in order to Jon Wolfers who created the php some years ago. Also many thanks to Benny Baumann who took care of adding rexx.php to GeShi and link rosetta to it! Please state whether you like it, hate it, want it removed, want it changed. Always trying and sometimes achieving something --Walterpachl

You may want to put a pointer in the category for REXX as well as this poll involves that language, more so than ooREXX as there are many more REXX entries than ooREXX. -- Gerard Schildberger 16:44, 9 June 2012 (UTC)

I vote NO, strongly and emphatically, for the use of the PHP for REXX. For REXX code, particularly with code that contains a significant amount of comments, I find the italicization almost dreadful to read. When I read (other's) REXX code, my eyes drift to the comments (especially if they are robust and plentiful) to get an overview of the program (which is especially important when I don't have a nary clue what that program is doing), and the italics really really make that difficult. I can't be the only older programmer that fading eyesight is becoming a problem. As for the highlighting, it too is distracting, and well, detracts from the readability and flow of the code. On the other hand, highlighting is nice for "strange" languages where I don't know what are keywords and what are variables, etc. When a language is more natural (to read), highlighting just gets in the way. I (try to) read a lot of other code, especially tasks that are very hard to understand, and some tasks (and many golf solutions/examples) are downright obtuse, so I spend a lot of my purusing time trying to read other languages solutions and I find that the ones with minimal highlighting much easier to scan/read. However, for the golf cases, for some strange reason, the comments are of the null variety, but that's another story. [We could start a whole new thread on the dearth of comments, and if ever there was a place for a huge amount of comments, Rosetta Code would be the place.] To me, it almost looks like someone got a new box of crayons and went ka-razy, thinking that the more colors, the better it looks. Nothing could be further from the truth. It would be nice if the hypertext preprocessor could be disabled by the user (trying) to read the source text. I don't mind it so much for my own code, as I just ignore the PHP version on Rosetta Code and edit a copy of the source code locally, which really shouldn't have to be the case, as the PHP is supposed to make reading the code easier, but instead it gets in the way. Walter Pachl (above) had an idea to possible use <lang crexx> for the coloring, and <lang rexx> for "normal" viewing. I beg your indulgence concerning the length of this entry as I'm trying to explain my rather intense feelings about this PHP. -- Gerard Schildberger 16:44, 9 June 2012 (UTC)

The purpose of the syntax highlighting is to make it easier for someone to read the code. In particular, one of the key purposes of Rosetta Code is to present languages to people who don't know them by means of idiomatic examples, and that is enormously easier for people when code is highlighted according to a “standard” scheme. The key common parts are that comments are one format, strings are a second (where supported by the language) and keywords (and keyword-like things) are a third. Like that, the structure of the code itself is apparent. Unlike with a larger project, here it should be possible to go fairly light on the comments; very long or very complex stuff is outside RC's scope (well, for reasonable definitions of “long” and “complex”; even that varies by language).

That said, GeSHi works by marking up the rendered code with HTML <span> elements that are labelled with the semantic class that has been identified for that part; you can override what they look like (e.g., turning off all foreground coloring and font changes for REXX) by supplying your own CSS overrides. Now, I admit I've never experimented with doing that sort of thing on MediaWiki, but I know others have on Wikipedia so it must be possible (and Google will be able to find out the details). That will give you what you want (unhighlighted code) without stopping others from getting what they want. (You'll want to apply an important override to all spans that are children of a <pre> that is of class “rexx”.) –Donal Fellows 23:40, 9 June 2012 (UTC)

I think going fairly light on the comments is going against the grain (philosophy) of what Rosetta Code is about. Comments help explain the code (obvious to experts) but very helpful for most people whose expertise isn't the language they're reading. I've been adding comments left and right as I go back frequently and try to better explain hows and whys of the (REXX) code; I can't believe that anyone would discourage comments (even verbose ones), heavy or otherwise, even those that might seem too obvious (if I understand what is being suggested). Hell's bells, I wouldn't mind a ten page dissertation on the J examples (probably all of them). Boy oh boy, that is some terse coding. -- Gerard Schildberger 07:37, 10 June 2012 (UTC)

Yes and no. :-) Write the code so that it is so obvious that it doesn't need so many comments, e.g., through careful choice of variable names or possibly refactoring into suitable procedures (with informative names). Keep comments for stuff that is harder to capture that way. Sometimes it can also be helpful to just add more blank lines and split the code over more lines so as to give it room to speak for itself. (I can't tell you exactly how to produce readable informative code, as so much of it is about æsthetics, but comments are definitely not the only tool in the arsenal for that fight…) –Donal Fellows 08:01, 10 June 2012 (UTC)

I vote YES, also strongly and emphatically, for syntax highlighting. I disagree with almost every point Gerard makes; I've always found that highlighting keywords makes it easier to follow the logic flow particularly when strange indentation styles have been adopted. I'd also like NetRexx included in the deployment if possible. (It's syntax is so Rexx-like I can't see it being much of a stretch.) P.S. There may be a better way, but inserting "angle brackets" (< and >) in the text can be done with the HTML tags "<" and ">". --Alansam 19:50, 9 June 2012 (UTC)

I also vote YES, although I find the italicisation a bit weird. It seems to be the mandatory style for comments on GeSHi.

I vote No. While I much prefer the clarity and universality of Walter's versions of Rexx task code, I must side with Gerard on GeSHi. Code highlighting is a valuable tool for debugging but I find it distracting (especially color) when trying to read Rexx. I have no problem with highlighting when the viewer can control what is being highlighted, but please don't inflict your choices on me. This is a language-dependent determination; {many {languages {especially {C} derivatives}} {benefit {from the metadata}} provided. :-} For Rexx, "code in black, comments in gray" is as far as I'd go.

The best reason to eschew syntax highlighting is that like Rexx token casing and clause indentation, it will be a constant source of contention. --Aviatrexx

So the opinions are arriving. Thanks I think you can see the black/white undistorted code when pressing Edit.

A possible solution to make everyone more or less happy would be to:

remove the rexx php from rosetta (it was worth a try)
add a crexx.php (essentially the current rexx.php - c stands for colored)
and an oorexx.php which takes care of the new keywords such as class, method etc. (they are curently also in rexx.php).

The best solution would, of course, be to have a switch to toggle between highlighted and plain display. But it's far beyond my reach whether this is feasible and even further to implement it. --Walterpachl 07:14, 10 June 2012 (UTC)

Categorically NO to “crexx” (well, unless someone produces a REXX variant that actually has that name after case-normalization). The parameter to <lang> is semantic, not just some flag to the highlighter; it's actually used for some of the off-line tools associated with RC. However, having a separate oorexx version is OK exactly because that is naming a language variation; it would cause different semantic markup to be applied (which might happen to include some extra syntax classes, but that's a side-effect).

It's also possible that tuning down the amount of highlighting would be a good idea; an example might be to not mark up numbers and parentheses. –Donal Fellows 07:52, 10 June 2012 (UTC)

Point taken. Someone said that the main obstacle (Italization of comments) cannot be removed. Is that true? Anyone any hope for the toggle? --Walterpachl 10:25, 10 June 2012 (UTC)

If you read the generated HTML, you'll see that all you've got is a <pre> (with a class attached) which contains text marked up with <span> tags, with classes. Changing what things look like is just a matter of changing the CSS style. Changing things dynamically is just a matter of changing the CSS dynamically. Modern browsers can do that (jQuery does so to great effect) so it is Just A Simple Matter Of Javascript Programming. Personally, I hate coding in JS (and also hate futzing around with CSS) so I won't work on togglable styles, but there's certainly sufficient in the way of hooks to do it, and I believe that there's the ability to hook running of your own custom JS when you view pages (but I don't know the details, and you've got equal access to search engines).

In short, you've got the tools available. Get coding! :-) –Donal Fellows 15:11, 10 June 2012 (UTC)

Thanks for the hint! Unfortunately not my area of expertise but maybe someone's

..Walterpachl 15:28, 10 June 2012 (UTC)

I vote YES, as syntax highlighting is an incredible enabler for comprehension of code. That is also the reason IMHO that practically every modern depiction of code has syntax highlighting. Or the other way around: if no syntax highlighting is available, it is very hard for interested readers who are not acquainted in detail with the syntax of a language to comprehend what is demonstrated in a short time. As we are talking about a Rexx language, which from its inception was intentionally "human centric", all the Rexx (and ooRexx) examples should be as short/simple as possible, using meaningful names for variables, such that the snippets become self-documentary. (Concurring empathically with what user Dkf above has stated and explained so well.)

Ad comments being shown in italic: this is fine with me as they remain easily legible, except the italics signal (in all languages) that the text is comment, making it easy to find the comment in longer programs.

Remember, syntax-highlighting is aimed at easying comprehension of code for anyone, but especially for newcomers, unacquainted but interested readers. Not applying it to ease comprehension, makes it unnecessary hard on the reader who (mistakingly) may attribute the language itself for being difficult to understand! The latter is also true for "clever programming" tricks in a language, which only could be appreciated by the ones in the know, but makes it impossible for newcomers to understand/comprehend the examples, hence making Rexx/ooRexx appear to be very difficult!

So please leave the "rexx" syntax highlighting in place and maybe create a GeShi variation for "oorexx", adding keywords and subkeywords introduced by it. (Also this may then be applied to the Sourceforge Wiki ooRexx samples to ease rading and comprehension.) --Rony 11:08, 10 June 2012 (UTC)

First I should say that the anonymous entry above was mine - it was not my intention that it should be anonymous, but that is how it appeared. This time of use, the editor appears with a useful toolbar and link to editing help.

I 'created' the PHP for GeSHi rexx colouring several years ago when I had some spare time, mainly with the intention that colouring should appear on the Sourceforge ooRexx wiki. It is the first and only PHP I have ever 'written' and I achieved it by plugging constants into a template. I submitted it to the GeSHi project, but for some reason it never got used.

I never saw how it rendered anything until yesterday.

I did not specify in that PHP what colours or styles should be applied to what elements of the language, only how to identify various elements. It is a long time ago now, and I cannot remember what is possible with GeSHi.

It never occurred to me that there were people in the world for whom syntax highlighting was anything other than a boon, although I do find some renderings over-fussy and as I said above, I find the use of italics as weird.

The decisions made here will apply to other Wiki based websites that use GeSHi.

So, whilst I am sorry to inconvenience Gerard, I must state a strong preference for syntax-colouring. This time, let's hope it is not anonymous. --Sahananda 16:09, 10 June 2012 (UTC)

It occurred to me that one litmus test of highlighting (or not highlighting) --- and that nobody brought up --- is what people use on their own computers.

I use KEDIT exclusively when editing REXX files. And I heartly endorse KEDIT coloring. It's very very good. The best best part is, it can be turned off!. I never use it.

It has one other good feature, it doesn't change the font, so NO italics! If you do like lighlighting, you can choose what colors are to be used for highlighting (if ya want it) for what thingys.

But I would drop KEDIT today if it forced it on me. Well, ok, I wouldn't drop it, I would just use an older version. At least, I have a say on what is productive for me. Fortunately, the author of KEDIT didn't force his idea of productivity or ease of use on me. Kudos.

I did also notice that nobody was clammering for highlighting for REXX, NetREXX, or ooRexx before it was enabled for REXX.

I also noted that the PL/I language which reads very much like REXX (one of REXX's parent) doesn't have highlighting, and nobody is clammering for its highlighting. If there were many more comments (heck, most programs seem to have no comments) in other example programs, there'd probably be a push to change the font from italics to, er, a plain font.

Somebody said (above) that we've got the tools available. Get coding!. Yeah, easier said than done. I really don't want to learn JS so I can read REXX code easier. I really don't like to have to learn a language to modify the behaviour of a syntax colorer.

If somebody has the expertise and can inform those that want it how to disable highlighting (and especially those italics!), there'll be a check coming in the mail to ya!

Be thankful that section and header comments are left alone! They may be next. -- Gerard Schildberger 08:36, 11 June 2012 (UTC)

With all respect to Gerard's work, I vote unambiguously YES for syntax colouring. LPEX, the live parsing editor (one of the first), is from Mike Cowlishaw, the maker of Rexx, and inspired by his work on the Oxford dictionary; there is objective evidence of the advantages of the use of colour. I use Emacs modes for NetRexx and ooRexx that closely follow the LPEX standards, including italicised comments.

As mentioned, while editing code, there is no colouring on Rosetta, so there cannot be distraction from that. Editing code for examples should be in each author's personal environment anyway. Syntax colouring increases the status of a language - it is a fact that the wider known/used languages have colouring, the lesser known/used have not. This argument extends to PL/I which influenced Rexx and also deserves the same treatment - it seems unjustly devaluated by being shown in plain black-on-white.

On a typograhical note: if italics are bothering, and sometimes they do bother me also, most of the time the quality of the font is bad - some just use transformations of the roman glyphs and not separate italic forms, as they should. In particular, older windows versions are terrible. Changing the default font might help here. I find having the comments in italics, and preferably sea-green, isolates them in the right way from code and does not force me to re-read the comments all the time. --Rene Jansen

I vote YES for syntax colouring as I've never seen anything else that makes code easier readable and in consequence more comprehensible especially to others. At this level I would describe syntax colouring as a no-brainer. I understand that someone feels no need to use syntax highlighting for himself, but it should be clear that he'll do a favour to others by providing it. --D.Macho 11:29, 11 June 2012 (UTC)