Talk:Idiomatically determine all the characters that can be used for symbols

What do you mean by "symbol"?

I have no clue what is meant by "symbol" here. To a semioticist, every character in the program is a symbol, and every meaningful group of characters is a symbol, and the entire program symbolizes the computation that will be performed when it is invoked. Most computer languages do not give a technical meaning to the term "symbol" (and those that do define it give differing definitions of it), but it feels as though a particular grammatical or cultural definition is being assumed here without explanation. RC entries should attempt to transcend cultural differences, not be trapped by them, so we either need to define specifically what is meant by "symbol" as a widely known concept of some sort, or find a less overloaded term that will communicate across differing computing cultures. Is "symbol" intended to be restricted to what other languages would call "identifiers"? Does it include operators or other action indicators? To us linguists, verbs are every bit as symbolic as nouns, and operators are just funny-looking verbs. On the other hand, if the intent is to use the term "symbol" as a sort of Rorschach blot for us to free associate from and interpret however we like, then that should be made clear too. It would not be the first RC task to take that approach. :-) --TimToady (talk) 17:14, 21 March 2014 (UTC)

I would've thought you'd get a clue from the first example entered (REXX). I didn't want to confuse symbols with characters (or a group of characters) within a computer program. If every character is a symbol, then we could just use the word character. As I meant/used/inferred it, symbols can be names of something, mostly used for names of programs/functions/subroutines/routines (another name would be entry points, specifically, the names of entry points), variable names (or structures), names (maybe called labels or events) of things that can be signaled/invoked (or trapped), etc. More generally, names that computer programmers can choose, as opposed to names of things that the compiler writers (or the architects) have chosen. I know that isn't specific enough to please most people, maybe not even some people; but I had to jump in somewhere. It wasn't my intent to exclude any computer programming languages that didn't have all (or if any) of the classes/types of symbols, nor was it meant to be so defined that some computer programming languages would/might be excluded. This is the main reason I tried to not define the word specifically so it might become exclusive (or start a definition war). My background in computer programming is mostly old school (FORTRAN, PL/I, COBOL, BASIC, IBM mainframe assembler, REXX, etc) where symbols have a more traditional (and somewhat confined) usage and/or meaning and usually exclude things like operators, types of statements, and (action) verbs --- and there are others, of course. I realized before I entered this Rosetta Code task, this would be fraught with the possibility of not adequately defining what a symbol is, but then, it wouldn't ever have been entered since there wasn't a definition where one-size-fits-all (computer programming languages). As for defining what a symbol is, and if a computer programming language has other meanings for symbols that can be programmatically determined, then that can be shown/defined in the examples. We could hash this out forever (trying to define what a symbol is in this context), but I feel there will never be a consensus on any one (specific) definition that would cover all computer programming languages, at least, on one definition that can't be agreed on without a long back and forth discussion. However, if there is a term for what I envisioned, I'd like to know what it is. If you could iron one out, give it a try (now that you know what I meant to ask for). I don't want this to evolve into a detailed discussion on the grammatics of computer science terminology on symbolism or a debate on computer programming cultures. -- Gerard Schildberger (talk) 18:29, 21 March 2014 (UTC)

If one computer programming language calls "them" identifiers, others call them names, others call them variables (variable names or names of variables, a miniscule difference), others yet call them labels ... What is needed is a term that can be understood by everyone what is meant. Tall order, but of which I have no clear term (or definition). -- Gerard Schildberger (talk) 18:39, 21 March 2014 (UTC)

I've added a general description of symbols to the task's requirement, I hope it's a start in the right direction (which is much better than reading my mind or viewing/decoding other examples). The phrase above Most computer languages do not give a technical meaning to the term "symbol" (and those that do define it give differing definitions of it), but ··· was my guideline, knowing full well that my attempt won't fare any better than give some (vague and/or general) description or examples. -- Gerard Schildberger (talk) 20:42, 21 March 2014 (UTC)

That's already a big improvement. Thanks. --TimToady (talk) 23:07, 21 March 2014 (UTC)

I suppose something like this wouldn't do? Those thingys that the what-ja-ma-call-its use for being a do-hicky for programers to use as variables? Seems clear to me. And Bob's your uncle. -- Gerard Schildberger (talk) 00:57, 13 September 2014 (UTC)

ooRexx is an Interpreter of Classic Rexx (and MUCH more)

A plea to Gerard Schildberger: Again and again you refuse to accept the fact that ooRexx is an interpreter that can perfectly process "classic" Rexx programs that obey a few (actually very few) restrictions. I added the modified program and its output to the Rexx section in order to make others aware of the difference. The program was actually also in Category ooRexx as you may have nodiced. Please reinstate my program instead of unjustly (re)moving it. --Walterpachl (talk) 19:52, 12 September 2014 (UTC)

BTW: Version 2 under ooRexx makes absolutely no sense!!! Please remove it --Walterpachl (talk) 19:56, 12 September 2014 (UTC)

Of course I refuse (again and again) to accept the (false) fact (see a variant above). It wouldn't make sense to refuse, refuse, refuse, refuse, and then accept. I also disagree on what a "few" is, not to mention very few restrictions. And even if listed, is the list a "few"? I looked up the word, and it is: a small number, one or two, or two or three, hardly any. Since they weren't listed anywhere, I don't know the number. You're setting up a straw-man argument here, and I could say the same thing about your beliefs, but that kind of argument is pointless, needless, and sophomoric. The fact that I consistently refuse to agree (regarding your statement above) with you shouldn't be berated, and this was the first time I've ever seen you use the word "perfectly" in that context, and I have no inkling what you mean by "perfect" (perhaps "always"?) That I refuse to accept a falsehood (consistently) or that I refuse (again and again) to accept one of your "facts" shouldn't be ridiculed. Let's keep this discourse civil, and about keeping ooRexx output(s) in the ooRexx language section. If you wanted to plea to me personally, you could just do what you normally do, write me an E-mail. You obviously have my address. -- Gerard Schildberger (talk) 21:30, 14 September 2014 (UTC)

Since you did not do it, I did it myself. Please leave these entries alone!

I shall respond to your answers to my questions later.--Walterpachl (talk) 18:48, 13 September 2014 (UTC)

Please note that I had moved an ooRexx language entry to the ooRexx language section. ooRexx entries should be in the ooRexx language section. -- Gerard Schildberger (talk) 18:54, 13 September 2014 (UTC)

How can you assume that I did not "note" (understand) this. One of my questions was what's wrong with showing how ooRexx executes a REXX program.
Is or isn't version 2 a Rexx program= --Walterpachl (talk) 19:05, 13 September 2014 (UTC)

If you want to show how ooRexx executes a REXX program, enter it in the ooRexx language section. This is the issue, not that the program can be executed (or not) with Classic REXX. The venue for ooRexx is in the ooRexx language section. -- Gerard Schildberger (talk) 19:12, 13 September 2014 (UTC)

The venue for REXX programs is the REXX section. I don't think that duplicating REXX programs under ooRexx makes sense. The ooRexx section is the place to show (off) oo features where possible. The sections address LANGUAGES not IMPLEMENTATIONS.--Walterpachl (talk) 19:19, 13 September 2014 (UTC)

It seems to me that the your logic is circular. If a REXX program can be executed (and IS executed) under (or with) ooRexx, enter it in the ooREXX language section. The REXX section is for Classic REXX implementations; ooRexx is a different language AND implementation (as witnessed by many differences, notably numerous options/features/capabilities/etc, whether or not they are being used in any specific example) --- in any case, the output is different, so please show that difference in the ooRexx language section. This just seems like a justification in entering an ooRexx execution under the (Classic) REXX language section. If using an ooRexx interpreter, enter it under the ooRexx language section. That is the venue for ooRexx. -- Gerard Schildberger (talk) 19:33, 13 September 2014 (UTC)

and I don't understand your logic. Why should a REXX program (and you seem to agree that version 2 is such an animal) not be entered in the REXX section. You show execution results for MANY REXXes. Why not also for ooREXX?

Could you enter the results of version 2 with all your other REXXes?
removing version 1 then would get rid of the expected redundancy. Maybe some independent opinion is asked for. Paddy? Michael?
Close to midnight here, so I'll shut up now. --Walterpachl (talk) 20:05, 13 September 2014 (UTC)

I show execution results for some Classic REXX interpreters that are convenient for me to execute (I have other Classic REXX interpreters, but they are a lot of trouble to set up and execute without stepping on my other installed classic REXX interpreters, so I rarely bother with them). I've entered one Classic REXX program and used (various) Classic REXX interpreters and shown their output. I've said it before, ooRexx executions belong in the ooRexx language section. The fact that ooRexx may execute a Classic REXX program doesn't make ooRexx a Classic REXX interpreter (I know this definition is arguable and is a bone of contention --- but if ooRexx executions would be placed in the ooRexx language section, this would be a moot point). PL/I may execute a Classic REXX program, that doesn't make PL/I a REXX interpreter; nor would anyone expect there be a PL/I entry entered/executed the REXX section to demonstrate that point. I see no reason to remove the Classic REXX version 1 program entry, there is no redundancy except for the misplaced posting/execution of an ooRexx entry in the Classic REXX language section. Version 2 (if executed with ooRexx) belongs in the ooRexx language section. As an aside, if ooRexx executes classic REXX programs, have it execute version 1. Yeah, I know, it's a tongue in cheek request. -- Gerard Schildberger (talk) 20:57, 13 September 2014 (UTC)

Perhaps the phrase tongue in ~~check~~ cheek isn't that well known or understood on the other side of the pond. I didn't mean for the error(s) to be posted, it was to show that a Classic REXX program being executed by ooREXX may (or may not) be execute correctly; hence, there is an ooRexx language section for executing the ooRexx interpreter. -- Gerard Schildberger (talk) 22:02, 13 September 2014 (UTC)

(Struke a typo, added correction). -- Gerard Schildberger (talk) 21:30, 14 September 2014 (UTC)

Let's get back to square zero (or rather column 1 here.
I DO understand "tongue in cheek" (never heard of "tongue in check" :-) and in better times I have corrected your spelling errors and/or typos). Adding ooRexx output for version 1 demonstrates clearly the point of this task and the thousands of lines we spent on "discussing" that matter.
Let's try to get to some common view.
The REXX Language Section is the place to show REXX programs solving a given task. One may show results with any Rexx interpreter or compiler. Results from other interpreters can and should be shown where this makes sense.
Not to permit what ooRexx does with a Rexx program is unacceptable. (showing what PL/I does with such a program does not make sense.) Ideal REXX programs (my definition) are those that concentrate on the task and give identical results for all REXXes. Sadly many of the programs you added and still add aren't ideal in this sense. Mine are.--Walterpachl (talk) 06:21, 14 September 2014 (UTC)

I apologize for the typo of the second mention of "tongue in cheek". Fortunately, the first use was spelled correctly, so I know you knew what I was referring to. (I've marked the typo and corrected it).

I have to disagree with your statement about the point of this task. The REXX language section if for (Classic) REXX; ooRexx interpreters (programs and/or output) should be placed in the ooRexx language section. Just because you can (or may) execute a Classic REXX program with ooRexx doesn't mean that you should enter the ooRexx's output in the (Classic) REXX section to show the difference --- (that's the reason PL/I was mentioned, but you've missed the point). That's why there's an ooRexx language section; you can show ooRexx's output there. If people want to know how NetRexx or ooRexx output(s) differ, they merely look in those language sections. That is one reason why there are language sections.

As for common views: stating that they are common views doesn't make it so. It should be obvious from these discussions that your statement isn't true.

The REXX language section is for Classic REXX; NetRexx and ooREXX have their own language sections to show their output(s), and they have their own language sections because of the many differences which differentiate those languages from Classic REXX (whether or not those other languages can execute Classic REXX statements/syntax or not). The REXX language section isn't a catchall place that you can add any varient or dialect (or ...), especially when ooRexx has it's own section. Claiming that you can add ooRexx under the Classic REXX section just because it makes sense to you isn't a valid reason, output from ooRexx shouldn't be added willy-nilly to other language sections. Output from ooRexx should be in the ooRexx language section.

Perhaps to make this point clearer: There are many BASIC language sections, yet no one is entering all manner of BASIC programs to other variants (dialects/versions/...) to each other BASIC language sections. It would just be one ginormous clutter. Everybody enters their version of a BASIC program into the respective BASIC language section. ... Regardless that a program could be executed by another BASIC compiler/interpreter. The same logic is applied here: ooRexx output goes in the ooRexx language section. I believe that this talk section header (title) of ooRexx is an interpreter of Classic REXX ... is probably the underlying basis of this discussion; ooRexx may interpret Classic REXX. Of course, that doesn't sound as good (and a bit hollow), but there are restrictions to what ooRexx will tolerate, as you've shown ooRexx to do with the (Classic) REXX version 1 of this Rosetta Code task. This should be obvious of one reason why ooRexx has its own language section. I've heard the argument that ooRexx handles all Classic REXX (even perfectly!?), and if ooRexx doesn't, then it's not Classic REXX. An interesting circular definition (and by the way, I'm not accusing anyone in particular of making such a statement and/or argument). The discussion then sometimes veers off about the definition (or lack thereof) of what Classic REXX is (or the lack of a clear definition), and statements about ooRexx being a Classic REXX interpreter, and so it goes.

I haven't in any way restricted what ooRexx does (or places its output) with any type of program when placing anything of ooRexx stuff in the proper section, ooRexx. ooRexx has it's own language section and you certainly have the right to include any manner of ooRexx output(s) to it's proper place: ooRexx. Just because ooRexx can or may execute some REXX program shouldn't give you carte blanche to enter ooRexx output to other language section, that is why there is an ooRexx section. ooRexx output belongs under ooRexx. This is the crux of my discussion. That you want to add the output of ooRexx yet to another language section (when ooRexx already has it's own language section) is just duplication and it clutters up the (Classic) REXX language section. If there are differences (or even if there aren't any), then show that in the ooRexx language section. You'll never see me enter a Classic REXX output in the ooRexx section just to show the differences. To me, that would be absurd, and it's strange that it isn't obvious to everyone. If you can agree to the obvious reason for that, than maybe you can see why ooRexx's output doesn't belong in the (Classic) REXX language section, but rather that ooRexx output(s) belong in the ooRexx section. That's where I would look to see what/how ooRexx solves a Rosetta Code task.

If you can't see my point about another language (PL/I for instance) executing the exact same code (as REXX or any language), then you're not looking at the bigger picture.

I don't know why you're introducing yet another definition ("ideal" programs), it hasn't been used before, and it appears that you're trying to define a word/phrase to help justify your adding of ooRexx output to the (Classic) REXX language section. As I read your definition (concerning identical results), well, hell's bells, none of the results (for ONE Classic REXX program) give identical results (except for those REXX interpreters which were written by the same programmer). This isn't the place to introduce a loosey-goosey definition to help justify cross-posting another's language program in the wrong language section. The (Classic) REXX language sections, as well as NetRexx and ooRexx sections) where around for quite some time now, and up to now, we've lived OK without adding another definition or criteria for "ideal" programs. This isn't an ideal world, and there are enough differences just between the Classic REXX interpreters, yet alone with ooRexx and NetRexx. ooRexx and NetRexx have their own syntax rules (some common syntax, but there are restrictions, and other extensions/capabilities/features/...), and is one main reason that they each have their own language section.

I'm really not the least bit interested in your definition of the REXX programs that I've entered, and whether or not they fit your "ideal" description. I enter Classic REXX programs (and note if they only work for specific implementations); I also prefer not to judge critically of others programs and post the criticism. It's more polite to just enter one's own version and not be insulting to another's handiwork. (My car is better looking than your car, and it's faster, and gets better mileage, AND has whitewalls?) People in glass houses shouldn't ··· Or, do onto others like you'd like to have them do to you.

If you'd just added the ooRexx output to the ooRexx language section, all this verbage wouldn't be necessary. I understand your agenda of trying to make it seem that ooRexx can execute all Classic REXX programs, but that doesn't belie the fact that ooRexx entries belong in the ooRexx language section. -- Gerard Schildberger (talk) 21:30, 14 September 2014 (UTC)

Whether or not an ooRexx program makes sense or not to be in the ooRexx section (category/language/etc) isn't the issue. The 2nd ooRexx version looked different enough in my eyes (and therefore not the same program), so it was moved to the ooRexx section (but the main reason was that the ooRexx program was an ooRexx program, and ooRexx programs have their own language section).

... And whether or not ooRexx has more features and facilities isn't the point either.

The REXX language (on Rosetta Code) is for Classic REXX, not for ooRexx (and as you know, ooRexx has it's own section).

If I find a language (such as Run BASIC) in the BASIC section, I'd probably move that also. It's not like that I'm deleting it or somesuch. Each language has it's own section, and I can understand why someone would mistakenly enter such a program under the wrong BASIC language section.

And, yes, I refuse to accept the statement (which is not a fact) that the ooRexx is an interpreter that can perfectly process Classic Rexx (there's no need to put the word classic in quotes unless you're referring to some other Classic REXX definition). (By the way, I use the definition of Classic REXX as defined in an IBM document quite a few years back which was published about the time that oRexx was being talked about, and there needed to be a better definition of what the REXX language was (as far as syntax, etc) versus the REXX language variant that was being discussed in the oRexx document). Please don't try to make out that I'm a bad guy for not accepting that statement as a fact (even if I do it again and again). It isn't a fact, so I shouldn't be put on the carpet that I refuse to accept a (false) fact (even if more than once). This isn't the place to argue about that statement and I don't want to be part of that myth. Also, the use of few (actually very few) restrictions wording depends on what you mean by few (put a number on it), and better still, list all the differences. Whatever the list is, it most likely won't be complete, and I have yet to see a comprehensive or itemized list. It shouldn't be that hard to draw up a list, after all, those differences should be known by the supporters and maintainers of ooRexx. As ooRexx isn't my dog, I have no interest nor do I have an agenda in compiling that list. That should be left to the people pushing the idea that ooRexx can perfectly process (or just process) any Classic REXX program. But the bottom line here is that there are enough differences (not to mention ooRexx's other features, capabilities, and options), which in my mind, make it a different language. I have never seen that list either (of ooRexx's expanded facilities) that are different from the features offered in any Classic REXX). But, whether or not I believe any part of such a statement, doesn't negate the fact that ooRexx has it's own language section, and that's where ooRexx programs belong, not in the Classic Rexx language section.

Also, it doesn't matter if ooRexx may execute a Classic REXX program (or not), ooRexx still has its own language section, and it exists for more than one reason (and I'll not go into listing them here --- but the ooRexx language section DOES exist, and it's for ooRexx programs) --- puting ooRexx programs yet into another language section is a waste of space on Rosetta Code and also user's time and effort when trying to find a Classic REXX solution. I have no agenda trying to push ooRexx (and it's claim that it can run/execute Classic REXX programs). We've been here before, REXX is for any Classic REXX interpreter, ooRexx is for the Object Orientated Rexx interpreter(s). I won't remove the (2^nd) ooRexx entry that was moved to the ooRexx section; if the original author wants to remove it, they can of course. Let's try to keep the two languages separate and refrain from entering ooRexx programs under the wrong language category. A while back, someone actually used the (my) Classic REXX program (in its entirety) and executed it in toto under another (non-REXX) language, and it produced exactly the same output (and it was noted as such in that other language's output section). That another language (not any form of REXX) correctly executed the Classic REXX program doesn't give me license to enter that Classic REXX program under another language (section), even though it executes the REXX program perfectly correct (sic). There is no need to enter an ooRexx program under two language entries (REXX and ooREXX). Putting another language under the REXX entry just to show the differences between Classic REXX and ooRexx is not the way to show the differences. One can just view the output of the ooRexx program (under the ooRexx section) and compare it with the program under the REXX entry to see the differences (that goes for NetRexx as well). Adding a duplicate version under the wrong or inappropriate section is contrary to the philosophy at Rosetta Code (as I understand it). I know there is a falsely-held belief that ooRexx will execute Classic REXX programs, but there is enough differences such that ooRexx has its own section, so the claim that ooRexx executes (all/some/many) Classic REXX programs is a mute point. I do understand that ooRexx may correctly execute some Classic REXX programs. But there are enough differences in the two languages that having ooRexx programs under the Classic REXX language section would just clutter up the entries in the REXX section; why make it more difficult for people who want to just look at Classic REXX programs and not have to wade through ooRexx programs as well? Putting ooRexx programs under the Classic REXX language section will also make it a royal pain in the neckhole if a person wanted to find an ooRexx program for a Rosetta Code task, and they had to look in two places, ooRexx and also (Classic) REXX. There are enough versions of Classic REXX programs as it is. That is one reason why ooRexx has its own language section, but certainly not the only reason). Furthermore, I certainly don't want to go through 700 different Classic REXX entries and label each of them as being Classic REXX and which Classic REXX interpreter that was used to test the program which produced the output (not the least of which are the mis-entered ooRexx programs in the Classic REXX section) --- it's always easy to suggest that somebody else do the work. So, that would be another reason to keep and have ooRexx entries in the ooRexx language section. Classic REXX programs in the REXX language section, ooRexx programs in the ooRexx language section, NetRexx programs in the NetRexx language section. -- Gerard Schildberger (talk) 00:48, 13 September 2014 (UTC)

I still have to carefully read your essay, bur let me ask a few questions:

Well, reading carefully is always a good thing to do (but I question what a few means). I choose to respond to your numerous questions point by point instead of lumping all the responses at the end. -- Gerard Schildberger (talk) 08:23, 13 September 2014 (UTC)

Is section REXX to contain REXX programs or implementations?

The REXX language section is for Classic REXX. ooRexx isn't a Classic REXX interpreter (I know, I know, saying that to some people is cause for fisticuffs). However, having said that, ooRexx may execute a Classic REXX program, but that isn't the issue. ooRexx programs should be entered in the ooRexx language section. The fact that ooRexx may execute a (Classic) REXX program doesn't negate the fact that ooRexx has it's own Rosetta Code language section. -- Gerard Schildberger (talk) 08:23, 13 September 2014 (UTC)

WHY do you mention NetRexx in your essay? Just to make it longer??

No, NetRexx is a REXX (or a REXX variant or something else, depending on which people you ask). But the question is moot, as there is a Rosetta Code language section for NetRexx, and that's where all the NetRexx programs have been entered. NetRexx program entries have never been added in the REXX language entry (... that I know of, it's possible that was done sometime in the past). The 2nd snide question isn't worth responding to. Try to remain civil here at Rosetta Code. It's a slippery slope. -- Gerard Schildberger (talk) 08:23, 13 September 2014 (UTC)

Can all REXX implementations that you use run my version successfully?

Again, that isn't the issue. What matters is that you entered and executed an ooRexx program with ooRexx in the (Classic) REXX language section. That's what the ooRexx language section is for. Enter ooRexx programs in the ooRexx language section. I have quite a few different Classic REXX interpreters, not all of which are easy to use with other REXXes being installed; not all REXX implementations play well together (er, ... that is, they can't be implemented without stepping on each other's toes, and for another thing, they all seem to want to be named REXX if only in part, ... go figure). -- Gerard Schildberger (talk) 08:23, 13 September 2014 (UTC)

Aren't my variable names more intuitive than yours?

Again, that isn't the question. This isn't a contest, Walter, of which program has the more intuitive variable names. Using intuitive variable names is a very subjective ... more black art than anything else. Not that this is germane, but I often see that when people talk about intuitive variable names, they are usually too long and fill up the program code space and programmers often use those names in lieu of comments or documentation. I believe there is no substitution for comments, but them's fighting words and I certainly don't want to start a debate on that topic. Again, ooRexx programs should be entered in the ooRexx language section. This shouldn't be about egos about who has the prettiest names, more intuitive names, better structure, better and/or consistent indentations, more comments, more whitespace, aligned comments (or not), better this, better that ... yada, yada, yada. -- Gerard Schildberger (talk) 08:23, 13 September 2014 (UTC)

What's wrong when I show what a particular implementation does with a program?

ooRexx should be entered in the ooRexx language section. That is the venue for ooRexx. If you want to show what an ooRexx program does, enter it in the proper language section. -- Gerard Schildberger (talk) 08:23, 13 September 2014 (UTC)

Does REXX have a changestr BIF?

It depends what REXX implementation (and/or which REXX language definition) you're referring to: TRL1, TRL2, ANSI REXX standard, what the IBM (CMS and/or TSO gold standard) does, etc. Or you could change the question slightly and ask which REXX interpreter does or doesn't have the changestr bif. This would be a good subject when discussing different (levels or implementations) of various REXX interpreters, but that would be a lengthy topic (or essay), but I'm not sure that information would be appropriate or valuable on Rosetta Code. But I certainly wouldn't stop anyone from attempting it. Collecting all that information from the numerous Classic REXX implementations would be daunting and time consuming. I wonder how many AREXX and/or OS/2 users are out there. -- Gerard Schildberger (talk) 08:23, 13 September 2014 (UTC)

As an aside, if Rosetta Code ever changes it ways and somehow lets me add new pages and/or links without that painful Captcha verification "system", I'll rename all the entries that don't seem to fit the Rosetta Code naming convention (including the changestr REXX subroutine). As it is (and I've mentioned it elsewhere on various Rosetta Code locations), and for whatever reason, I (and others) have a painful (and time consuming) time getting the information to be displayed correctly (or in my case, not displayed at all). What I have to do is wait for some amount of time, usually forcing me to shutdown all other windows (ugh), and then request an audible prompt, then ignore the gawd-awful sounds (more noise than anything), and then request a typed prompt. "Replay" doesn't work. This jig has to be repeated a number of times. Now THAT is something to sigh about. It usually takes me anywhere from a ¼ hour to an ½ hour, sometimes more if there are other updates being done to the same page. This is the main reason that I've stopped entering Rosetta Code (draft) tasks. And don't get me started on adding/changing/correcting a link. Sheesh. -- Gerard Schildberger (talk) 08:43, 13 September 2014 (UTC)

Why do you ever so often say "some REXXes~ don't contain... CHANGESTR," for example?

Simply because at least four of REXX interpreters that I know of do not have the changestr bif, so I mention it and point to a version that does work for all (Classic) REXX interpreters. By the way, if you know of a REXX entry (of mine) that uses changestr and doesn't have a mention of the link to the changestr subroutine, please give me a shout on my user talk page, and I'll fix that. -- Gerard Schildberger (talk) 08:23, 13 September 2014 (UTC)

Where did I ask you to rewrite your programs to please ooRexx (and me)?

I don't understand your question. When did I stop beating my wife? -- Gerard Schildberger (talk) 08:23, 13 September 2014 (UTC)

WHAT's WRONG with my statement "ooRexx is an interpreter that can perfectly process "classic" Rexx programs that obey a few (actually very few) restrictions."?

I don't know what you mean by perfectly process, but I am assuming that it means to process (execute?) without failure (as in being upward compatible). I also don't know what you mean by "few", or actually, very few restrictions. Put a number to the word few, and a list would be better. Whether or not ooRexx can or can't execute a (Classic) REXX program, ooRexx programs should be entered in the ooRexx language section. What is the ooRexx language section for? Are ooRexx programs to be entered then in two different language sections? That situation would beg duplication (or redundancy). -- Gerard Schildberger (talk) 08:23, 13 September 2014 (UTC)

Why do you delete other person's programs?

Please be specific. Which programs (and where) did I delete other person's programs? Are you talking about REXX programs, or are you just shooting a shotgun here? This is one reason why almost everybody doesn't sign their signatures to a program, the entries belong to Rosetta Code (as I understand the statements at the bottom of every screen page when editing is being performed), and I hope I'm using the correct phraseology. Maybe esteemed others could add a few words here about program entry ownership (or lack of it). -- Gerard Schildberger (talk) 08:23, 13 September 2014 (UTC)

Why do YOU add a REDUNDANT program to the ooRexx section?

If you're referring to the different version of an ooRexx program that was entered in the (Classic) REXX language section that was then moved to the ooRexx language section, it looked different to me, it executed with different statements, and had different output. If it was (or is) redundant, then it shouldn't have been entered at all. And if you think the ooRexx program is redundant, then remove it. -- Gerard Schildberger (talk) 08:23, 13 September 2014 (UTC)

SIGH --Walterpachl (talk) 05:58, 13 September 2014 (UTC)

I share your sighing. This too is getting old for me, all that is being discussed here (essay or not) is a rehash of ooRexx and (Classic) REXX differences (or execution of same depending on some number of unnamed restrictions, at least, not named here on Rosetta Code). There shouldn't be this amount of snipping or snide questions. If you need to classify what I write as an essay, that's OK, essays should be wrote carefully and be read carefully, and I try to choose my words carefully and I'm trying to informal as well while being accurate. It's not my intent to quantify the differences. My only point (and I've said it a few times, please enter ooRexx programs in the ooRexx language section. It's a simple application of the golden rule. How would anyone feel if I would enter "correct/working" (Classic) REXX entries in the ooRexx language section? Keeping ooRexx programs in the proper language section makes all these issues go away. I've written what I meant to say as clear as I can. If you would enter ooRexx programs in the ooRexx language section, there wouldn't be a need to discuss at length the differences between ooRexx and (Classic) REXX programs and/or interpreters and/or implementations. Another bad thing about entering an ooRexx entry in the (Classic) REXX language section is, how can anyone else find out which Rosetta Code tasks don't have a (Classic) REXX entered? When perusing the tasks not solved for REXX would have an entry (well, it would be an ooRexx entry). They would have to look at every Rosetta Code task (and drafts) to find out which (Classic) REXX entries are actually ooRexx entries, and not (Classic) REXX entries. That defeats the purpose of having a list of unsolved Rosetta Code tasks (or unsolved draft tasks). -- Gerard Schildberger (talk) 08:23, 13 September 2014 (UTC)

entering ooRexx entries in wrong language section

I see an ooRexx language entry was again incorrectly added to the (Classic) REXX language section. ooRexx has it's own language section; nowhere else is there cross-posting of entries of one language (with it's own language section) into a different language section (there may be exceptions on talk pages, but I don't know that). If more explanation is needed, the above (preceding) talk section can be reviewed. Perhaps it would be equitable if modified (for those differences that ooRexx can't handle) Classic REXX entries were also entered under the ooRexx section? Of course not. The venue for ooRexx examples is in the ooRexx language section. Entering an ooRexx entry in the Classic REXX section to show the differences from ooRexx isn't way to do that. -- Gerard Schildberger (talk) 19:08, 13 September 2014 (UTC)

I don't see any benefit of these editing skirmishes. It's become a colossal waste of time in trying to explain that ooRexx entries belong in the ooRexx language section, irrespective of what ooRexx can or can't support. If it is believed that cross-posting of one language into another language section is acceptable and permissible, I won't move it the 3^rd time. My time is more valuable then trying to keep ooRexx progams in the ooRexx language section. -- Gerard Schildberger (talk) 19:08, 13 September 2014 (UTC)