I really do not think that allowing literal strings to cross lines would be
an improvement. REX had this for some years -- and the pain it caused the
'average' programmer was enormous -- I had hundreds of e-mails from confused
programmers on exactly that problem -- and the pain was instantly fixed by
the 'literals must be complete on a line' rule. This also avoided all the
problems of gaining extra spaces in a string when adding indention to a
piece of code. Changing this to make obscure rare cases easier to code is
negative leverage.
Comments are different because they have matching pairs of different
notations. Which does lead to a suggestion: a new notation for 'multi-line
literal' that
a) has different start and end forms
b) is not easily confused with the existing literals notations.
It could also allow NetRexx-style escapes in the new form of literal string,
for example:
/" this is a new string\n\rwhich is two \"lines\" in one "/
... or something like that ...
The downside is that it is yet another new notation; more to learn.
Mike
_____
From: Rony G. Flatscher [mailto:rony.flatsc...@wu.ac.at]
Sent: 19 October 2016 13:54
To: oorexx-devel@lists.sourceforge.net
Subject: Re: [Oorexx-devel] Multi-line literals
On 19.10.2016 11:37, René Jansen wrote:
I beg to differ here. Now it means that every sublanguage fragment needs
to be embedded in quotes, checked on quotes in comments or embedded quotes
of the other type - which needs extra escaping. Indeed SQL is also my main
worry here.
The funny thing is that a variant of the same phenomenon, caused by all this
escaping, leads to the exact same error. In particular on the mainframe I
commit this error often: I have a block of SQL tested and lifted out of DB2
Admin tool, want to use in in an exec and drop it in an ISPF/PDF member.
Then I make one line starting with and ending with , and use ISPFs block
overlay feature, which is neat. Then, invariably, someone walks in and
distracts me for a microsecond. Half an hour later, having put several
traces in called functions, I remove that last comma and the thing works.
Several people have devised schemes with sourceline and special comments
to do exactly this. Unfortunately, with NetRexx I could not get this to work
(yet). With the other languages having this, and it being a legitimate cause
to point out as omission, I would worry less about forgetting the closing
tag - my editor would do that for me on entering the opening tag nowadays -
my vote is with adding this facility.
+1
Multiline-literals are available in other programming languages, as they
alleviate coding for specific situations like SQL-statements, but also
HTML/XML-text spanning multiple lines, and the like. It would also allow for
concatenating multiline-literals with variable values, something the
resource directive would not allow for.
If an ending quote is missing the same situation would arise as if a
multiline comment /* was not closed, something the interpreter makes the
programmer aware of, giving the exact reason and the position where the
comment was opened, e.g.:
F:\test\oorexx\rgf>type test.rex
say 1 + /* this
is a /* multiline */ comment
that does not get closed
1
F:\test\oorexx\rgf>rexx test.rex
1 *-* say 1 + /* this is a /* multiline */ comment that does not
get closed 1
Error 6 running F:\test\oorexx\rgf\test.rex line 1: Unmatched "/*" or
quote.
Error 6.1: Unmatched comment delimiter ("/*") on line 1.
F:\test\oorexx\rgf>
As multiline literals would really help programmers in specific coding
situations, I would also think that it is worth adding it to ooRexx.
---rony
On 15 Oct 2016, at 11:24, Mike Cowlishaw <m...@speleotrove.com> wrote:
As Rick said. Also it means that the error message about a missing
(unmatched) quote can exactly pinpoint the line where it occurred.
Mike
_____
From: Rick McGuire [mailto:object.r...@gmail.com]
Sent: 14 October 2016 22:04
To: Open Object Rexx Developer Mailing List
Subject: Re: [Oorexx-devel] Multi-line literals
They were removed from the language because in practice, they resulted in
lots of problems when a closing delimiter was accidentally omitted. It was
pretty easy for a missing quote to swallow up large sections of the program
without error.
I'm not particularly in favor of adding this.
Rick
On Fri, Oct 14, 2016 at 4:37 PM, Erich Steinböck
<erich.steinbo...@gmail.com> wrote:
I had a look at the REX folder which mfc has provided at
http://speleotrove.com/rexxhis
<http://speleotrove.com/rexxhist/rexcard-208-scan.pdf>
t/rexcard-208-scan.pdf and saw that we had multi-line strings already back
in 1980. So I'd like to reopen the discussion about adding multi-line
literals. (This is not imbedded data - now available through the ::RESOURCE
directive in 5.0 - but inlined literals.)
At first, what was the reason we lost multi-line strings (starting with a
simple quote, and spanning multiple lines)?
What about re-introducing them, either with a third type of quote (e. g. ` )
or some double-character quote (e. g. `" multi - line string "` )
On Sat, Jun 14, 2014 at 6:32 PM, Rick McGuire <object.r...@gmail.com> wrote:
I do for see a use for multi-literals, but I don't really see them as being
a good usage for the type of problem I'm trying to solve here. The
directive approach is really intended for situations where I really wish to
embed a file within a single source program rather than having it elsewhere.
I most definitely do not want all of that date plunked in the middle of
logic, particularly if it is quite large. Additionally, the directive
approach means that data is available to other sections of the code, not
just in the context where it happens to be coded. Additionally, since I
envision this data being obtained from the package directive, it can be made
public, which means other consumers of that code can obtain access to the
data.
I'm not adverse to multi-line literals...in fact, they would be quite useful
for things like dynamically defining methods or embedding snippets of XML
code, but can we separate the discussions of these two features, since they
really solve different problems.
Rick
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
