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
> 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.
+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
>> <mailto: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
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
