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 ISPF’s 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.
best regards,
René.
> 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
>> <mailto:erich.steinbo...@gmail.com>> wrote:
>>> I had a look at the REX folder which mfc has provided at
>>> http://speleotrove.com/rexxhist/rexcard-208-scan.pdf
>>> <http://speleotrove.com/rexxhist/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
>>> <mailto: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
>>> <http://sdm.link/slashdot>
>>> _______________________________________________
>>> Oorexx-devel mailing list
>>> Oorexx-devel@lists.sourceforge.net
>>> <mailto:Oorexx-devel@lists.sourceforge.net>
>>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>>> <https://lists.sourceforge.net/lists/listinfo/oorexx-devel>
>>>
>>
> ------------------------------------------------------------------------------
> 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
------------------------------------------------------------------------------
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
