Menu
▾
▴
#416 Allow ` accent as third quote type
I would like to see ooRexx support the ` accent character as a third quote delimiter. Justification: When ooRexx is used to generate code in other languages (or even to generate Rexx source) or if ooRexx is used as a macro language for an editor, it may have to deal with both single and double quotes as data. This is especially true if this is being done via a string being passed to a Rexx subcommand handler.
Having accent as a quote type would help avoid quote-doubling, and would make the commands easier to read. Here is an example from ISPF, using this syntax:
ADDRESS ISREDIT
ISREDIT CHANGE T"isn't" C"don't"
Discussion
Anonymous
I think this is a bad idea as it just increases the complexity of possible string literals. In no time at all someone will want a 4th and then a fifth quote character to cope with strings that contain the previous 3 or 4 quote characters as literals.
I think when a string has a complicated content it's better to build it up from constituent parts - it certainly makes editing the contents of the parts easier. For example:
command = "change"
dblquot = '"'
fromtxt = "T" || dblquot || "isn't" || dblquot
intotxt = "C" || dblquot || "don't" || dblquot
Although it wouldn;t work in this case (because of the intended difference in 'T' and 'C' operand flags), my own preference would normally be to avoid the complexities of having to quote strings which contain arbitrary content by using hex arguments:
address isredit "change x'" || c2x(fromtxt) || "' x'" || c2x(intotxt) || "'"
The same technique is a handy way to pass strings as one-word/token arguments between execs.
The objection to accent quotes on the grounds that "someone will want a 4th and 5th quote type" is short-sighted and misses several points.
First, there actually IS a character to use for a third quote type - the accent character to the left of the 1 key on US and many other keyboards.
What would such hypothetical 4th and 5th quotes be? Nearly all graphic characters that could be used in ooRexx are already in use.
It is true that some languages allow user-defined composite symbols for special-purpose quoting. The need for such special quoting must exist, or else no one would have implemented such things. However, my proposal here is nothing of the sort. It is unreasonable to object to the proposal at hand on the basis that "someday, someone" might ask for some new, additional feature - one I never mentioned myself - that would complicate the language; and, that because this hypothetical future proposal is "bad" that somehow it makes the current proposal "bad by association" or something. We are not speaking about the future. We are discussing the current proposal here, today. Let us stay focused on the matter at hand.
No one is disputing that with tedious, cryptic string expressions and double-quoting, you can create any sort of string you wish. The point is, we shouldn't have to go through those contortions to do so.
Because Rexx is commonly used not only as a macro and scripting language, but as a tool to generate source code in other languages (say, in C or C++), it becomes a great burden for users to have concatenation operatars and quote doubling as the only means of generating such code.
Finally, it may be observed from an inspection of the source code, that very little code will be affected by this proposed change: a handful of lines in scanner.cpp to allow the accent quote, and a few entries to properly report unclosed accent-quoted strings in case of error. All told there couldn't be more than 2 dozen lines all told, so little you could knock it out in 20 minutes.
Shortsighted... if the language REALLY needed another quote character, how come we've all managed fine until now?
Suppose this third quote character is added to Rexx. How then would you write a string that contains all three of the existing valid quote characters? If you weren't going to use concatenation of substrings, you'd need a fourth quote character. It seems to me that any RFE that doesn't solve a problem, just buries it a bit deeper is not worth having.
Pardon me, but wouldn't that objection be true of every single enhancement ever added to ooRexx? "If the language REALLY needed -[ fill in the blank with every feature EVER added to ooRexx ]-, how come we've managed fine until now?" That argument is as weak as it is cynical.
Q: "Suppose this third quote character is added to Rexx. How then would you
write a string that contains all three of the existing valid quote
characters?"
A1: Just as you say, with concatenation and quote doubling.
A2: I often deal with languages that have two quote types; Rexx itself, and C/C++ are two examples. I almost never deal with languages that have three. The fact is, for ooRexx code that would be used to generate most typical source code that developers run into, the accent-as-third-quote rule would solve 99% of the problem.
Yes, if I had all 3 quotes as data, something would have to give, just as you point out. However, it's imporant to be reasonable. The likelihood of that happening is very small, while the likelihood of running into both single and double quotes as data when generating source code is very high. The two situations are not the same and not comparable.
You say that " It seems to me that any RFE that doesn't
solve [ every conceivable] problem, just buries it a bit deeper [and so it ] is not worth having." That seems a rather extreme position. I am not aware of any software solution ever created that could solve all problems. I never claimed or proposed that this one would either. I am claiming it would be helpful and useful.
Now, yes, there are more elaborate solutions that are possible. For example, the C++0x standard defines "raw strings" that omit the \ escape mechanism and which have user-defined delimiters using the notation R"<delim>(string)<delim>".
(See http://en.wikipedia.org/wiki/C%2B%2B0x#User-defined_literals).
However, implementing such an approach would take extensive modification of the scanner.cpp module, and would be more difficult to implement, debug and document, since the lexical rules follow unusual and non-typical semantics. That is not the case with an accent quote: The mechanism works EXACTLY the same as single and double quotes. That's why the modification to scanner.cpp is so easy.
Suppose you implemented the C++0x raw-string approach in ooRexx. That wouldn't "solve the whole problem" either, because it doesn't handle multi-line constants, like the triple-quote notation of Python. And Python probably doesn't handle embedded hex values, DBCS-EBCDIC, UTF-32, etc.
Whatever shall we do? Are we suppose to wring our hands, say boo-hoo, and give up because this extremist all-encompassing solution is beyond your grasp? I am sorry, but I cannot help but repeat the word cynical to describe your position. What it is that is so greatly bothering you about this?
I cannot help but wonder what sort of objections you raise to really complex technical issues. Wow, no wonder it takes a year to get new releases out.
Honestly, I see your objections as obstructionist and unreasonable.
Your "That argument is as weak as it is cynical." misses the point that REXX has managed 30+ years without a third quoting mechanism. I think you should really think about the difference between what (I'd say) is the elegance of allowing both single and double-quoted strings - which provides a simple mechanism through which any string can be assembled easily - and proliferation of features which add little.
In the latter part of your reply you attack me. I don't think that helps your case, not least because you seem also to have assumed I'm a developer - which I'm not. I'm just another user. What's bothering me? Elegance versus needless extra features.
You've also said you think the development process is slow. So you've also in passing commented unfavourably on the volunteers who do the development. That'll impress them, I've no doubt.
None of my remarks were intended as an attack on anyone. I have seen too many online forum characterized by bickering and hostility, and I have never believed there is a place for that in software development. It ought be a calm, measured yet rigorous exploration of software design issues. Having said that, I am deeply troubled by the very negative and dismissive tone of these remarks and I don't really appreciate them, which could basically be summarized as "the answer is No; what was the question again?".
Rexx came into existence at a time when mainframe systems were prominent, and most of them had only the single quote, since the prevailing 1403 printers usually came with print chains only having the one quote on the print chain, to reduce the available characters and speed up printing. For Rexx to have two available quotes was novel in its day.
Every argument against a third quote could be applied to Rexx having two quotes. Just as Rexx has supposedly done fine without 3 quotes, they could have also done fine without 2. That's how mainframe assembler, PL/1 and even COBOL did it. COBOL couldn't even double their quotes; you had to say VALUE QUOTE.
It could have been said for the original design, "what do you need two quotes for? Every other language as gotten alone just fine with one." And, Mike Cowlishaw no doubt would be unable to defend his position against arguments identical to yours, as you evidently feel I am unable to defend my position now.
Please understand, I don't need the ooRexx developers to come up with a solution. I already know how to modify the source code to accomplish this. It would take all of about 20 minutes to modify the code, and if I skipped the creation of specific messages to handle missing-close-quote issues, I could change the code in 10 minutes. My proposal was not for my benefit, but to suggest an easy and reasonably useful feature, one that is easy to understand, explain, document and implement.
I have no interest, vested or otherwise, to argue about this, nor is there any need to. The suggestion stands or falls on its own merits.
As it appears that argument is the only form of discourse engaged herein, I am withdrawing my SourceForge account. I won't be a part of this.
Robert, I hope you haven't given up your efforts to improve ooRexx in frustration over resistance to your suggestion. As an original member of the Rexx ANSI Standard committee, I can assure you that many, many ideas to improve the language were submitted, and very few prevailed.
There are several major factors that come into play when contemplating changing ooRexx:
1. Is it Rexx-ish (consonant with the "Rexx Philosophy")?
2. Can it be implemented universally?
3. Does it cause breakage or have untoward side-effects?
4. Is it necessary, or merely a convenience?
etc.
For example: does this feature "keep the language (conceptually) small"? Does it raise or lower the "astonishment factor" for novice programmers? Does it reflect the user's view of reality? And so forth. This sets the bar relatively high for aspiring features, but then again, this ain't Perl.
Just for starters, I will mention that none of my smartphones have a back-quote on any keyboard. Also, this proposal will break every Rexx program that uses the back-quote in a literal. Also, my mother (I use her as a metric for human-centric features) has never seen a back-quote and would surely want to close it with a non-existent "forward-quote".
Then there is the human-factors issue of the readability of the '`' in most fonts. It's almost indistinguishable from the single-quote here in this SourceForge edit box.
And I don't know if you've been keeping up on the Unix/Linux sphere, but the back-quote character is being deprecated for its only function, command substitution, in favor of a more regular, extensible notation. Remember when keyboards had the cent-sign? I predict the same fate for the back-quote.
I will concede that you have the "implementable" ( if not "universally implementable") argument nailed. But given the talent of the ooRexx development team, that's not saying much. :-)
The ANSI committee had to address the proliferation of "not" signs in the various Rexx implementations of 1990's. There were at least a half-dozen. Specifically rejected was the original "lazy-L" not-sign of the 3270 keyboard, because is was not universally available. Also rejected was the tilde for the same reason. It's a good thing too, because that left it available to be used as the "message send" operator of ooRexx.
Finally:
This discussion was proceeding as "a calm, measured yet rigorous exploration of software design issues" until your hyperbolic and ad hominem response on 1/26. I got the impression that Jeremy was objecting on gut-level "Rexx-ish" grounds, and he pointed out that there was a way to handle this problem in the relatively few cases where it occurs. Your arguments boiled down to "this will help me" and "it's easy to do". That way lies Perl, and Ada, and many other well-intentioned "kitchen sink" languages.