Re: [Oorexx-devel] Multi-line literals
> As long as we're going "extra-ANSI", wouldn't the square > brackets [ ... ] be more indicative of a "block" of data? Or > are they already being used and I missed it? Already used. For example, pretty much all my memowiki page Rexes start: use arg data., source, html, kind signal on novalue root=data.['#root'] delim=right(root,1) (delim needed to detect whether running on Linux or Windows...) -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Multi-line literals
I've had this idea in the back of my head for a literal that could be
converted into an object of a particular type, for example, XML, Using a
second trigger character like that would allow the type to be specified. For
example,
specs = {/XML'
...
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Multi-line literals
As long as we're going "extra-ANSI", wouldn't the square brackets [
... ] be more indicative of a "block" of data? Or are they already
being used and I missed it?
-Chip-
On 11/2/2016 9:48 AM, Mike Cowlishaw wrote:
>> +1
>
> Equally to 'blow' the use of {} for just one rarely-needed syntax would be a
> profligate waste :-).
>
> So, reserving a character inside for specific purposes would make sense (and
> make the notation more obvious -- we know all too well that in some fonts,
> etc., it's hard to tell '{' from '(', as every C programmer has learned the
> hard way :-}.
>
> So, maybe: {"escapable character string\n... like NetRexx"} and perhaps
> allow {'this too'}. This would allow future extensions using { and } for
> other purposes -- such as to include C code [{C ..?.. C}], or regular
> expressions.
>
> (I always thought early Pascal's comment syntax (* ... *) was better than
> PL/I's /* ... */ because of its better indication of start and end.)
>
> Mike
>
>
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Multi-line literals
I've had this idea in the back of my head for a literal that could be
converted into an object of a particular type, for example, XML, Using a
second trigger character like that would allow the type to be specified.
For example,
specs = {/XML'
...
wrote:
> > +1
>
> Equally to 'blow' the use of {} for just one rarely-needed syntax would be
> a
> profligate waste :-).
>
> So, reserving a character inside for specific purposes would make sense
> (and
> make the notation more obvious -- we know all too well that in some fonts,
> etc., it's hard to tell '{' from '(', as every C programmer has learned the
> hard way :-}.
>
> So, maybe: {"escapable character string\n... like NetRexx"} and perhaps
> allow {'this too'}. This would allow future extensions using { and } for
> other purposes -- such as to include C code [{C ..?.. C}], or regular
> expressions.
>
> (I always thought early Pascal's comment syntax (* ... *) was better than
> PL/I's /* ... */ because of its better indication of start and end.)
>
> Mike
>
>
>
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Multi-line literals
come to think of it, I think it would be better if the delimiter cannot be on
the same line.
JCL has:
//DD1 DD *,DLM=AA
.
.
data
.
AA
which always suited me fine. Just paste a block in there.
Python has “here documents” which look … similar:
COMMAND < On 2 nov. 2016, at 14:48, Mike Cowlishaw wrote:
>
>> +1
>
> Equally to 'blow' the use of {} for just one rarely-needed syntax would be a
> profligate waste :-).
>
> So, reserving a character inside for specific purposes would make sense (and
> make the notation more obvious -- we know all too well that in some fonts,
> etc., it's hard to tell '{' from '(', as every C programmer has learned the
> hard way :-}.
>
> So, maybe: {"escapable character string\n... like NetRexx"} and perhaps
> allow {'this too'}. This would allow future extensions using { and } for
> other purposes -- such as to include C code [{C ..?.. C}], or regular
> expressions.
>
> (I always thought early Pascal's comment syntax (* ... *) was better than
> PL/I's /* ... */ because of its better indication of start and end.)
>
> Mike
>
>
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Multi-line literals
> +1
Equally to 'blow' the use of {} for just one rarely-needed syntax would be a
profligate waste :-).
So, reserving a character inside for specific purposes would make sense (and
make the notation more obvious -- we know all too well that in some fonts,
etc., it's hard to tell '{' from '(', as every C programmer has learned the
hard way :-}.
So, maybe: {"escapable character string\n... like NetRexx"} and perhaps
allow {'this too'}. This would allow future extensions using { and } for
other purposes -- such as to include C code [{C ..?.. C}], or regular
expressions.
(I always thought early Pascal's comment syntax (* ... *) was better than
PL/I's /* ... */ because of its better indication of start and end.)
Mike
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Multi-line literals
+1
> On 31 okt. 2016, at 20:48, Rick McGuire wrote:
>
> Well, there's always { and }, which never gets used because we're constantly
> saving them for something in the future.
>
> Rick
>
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Multi-line literals
On 31.10.2016 20:48, Rick McGuire wrote:
> Well, there's always { and }, which never gets used because we're constantly
> saving them for
> something in the future.
>
> Rick
+1
> On Mon, Oct 31, 2016 at 3:16 PM, Mike Cowlishaw >
> wrote:
>
>
>
>
> Using /' ... '/ or /" ... "/ for multiline literals
>
>
> This is not an option, as e. g. say 2 /" 3 "/ 4 is already a valid
> expression
>
>
> Indeed; I was definitely not suggesting a specific syntax, just trying to
> indicate the concept.
>
> Mike
>
Using {, } instead of /", /', '/, "/ in the examples of my last post even would
improve legibility
even more:
This also makes it easier to use (unescaped) single and double quotes as
many times as one sees
fit within a string literal, e.g.
str= { this is a multiline literal using a "double", a ""double
double"", a 'single' or
\n\ta double ''single'' quotes without a problem } str= { this is a
multiline literal using
a "double", a ""double double"", a 'single' or \n\ta double ''single''
quotes without a
problem }
Additionally, it becomes possible to have block and line comments unescaped
in such a multi-line
literal, e.g.
say { this is a multiline literal that allows one to use 'single' or
"double" quotes within
the same string as well as /* comment-like */ text as well as -- double
dashes. \n\tthis was
a newline char followed by a tab char }
So for example a SQL-statement could be changed from currently (almost
illegible, example
extracted from a post to RexxLA):
sql_cmd = "INSERT INTO wp_posts
(","'ID',","'post_author',", "'post_date',", "'post_date_gmt',",
"'post_content',", "'post_title',","'post_excerpt',", "'post_status',",
"'comment_status',", "'ping_status',", "'post_password',", "'post_name',",
"'to_ping',", "'pinged',", "'post_modified',", "'post_modified_gmt',",
"'post_content_filtered',", "'post_parent',","'guid',", "'menu_order',",
"'post_type',", "'post_mime_type',",
"'comment_count')","VALUES(","'"gp.ID.1"',","'"gp.post_author.1"',","'"gp.post_date.1"',","'"gp.post_date_gmt.1"',","'"gp.post_content.1"',","'"gp.post_title.1"',","'"gp.post_excerpt.1"',","'"gp.post_status.1"',","'"gp.comment_status.1"',","'"gp.ping_status.1"',","'"gp.post_password.1"',","'"gp.post_name.1"',","'"gp.to_ping.1"',","'"gp.pinged.1"',","'"gp.post_modified.1"',","'"gp.post_modified_gmt.1"',","'"gp.post_content_filtered.1"',","'"gp.post_parent.1"',","'"gp.guid.1"',","'"gp.menu_order.1"',","'"gp.post_type.1"',","'"gp.post_mime_type.1"',","'"gp.comment_count.1"'",")"
to a better legible (less error prone) version:
sql_cmd = { INSERT INTO wp_posts ('ID', 'post_author', 'post_date',
'post_date_gmt',
'post_content','post_title', 'post_excerpt', 'post_status',
'comment_status','ping_status',
'post_password', 'post_name', 'to_ping','pinged', 'post_modified',
'post_modified_gmt','post_content_filtered', 'post_parent',
'guid','menu_order','post_type',
'post_mime_type', 'comment_count' )VALUES('}gp.ID.1{',
'}gp.post_author.1{',
'}gp.post_date.1{', '}gp.post_date_gmt.1{','}gp.post_content.1{',
'}gp.post_title.1{',
'}gp.post_excerpt.1{','}gp.post_status.1{','}gp.comment_status.1{',
'}gp.ping_status.1{','}gp.post_password.1{',
'}gp.post_name.1{','}gp.to_ping.1{','}gp.pinged.1{','}gp.post_modified.1{','}gp.post_modified_gmt.1{','}gp.post_content_filtered.1{','}gp.post_parent.1{','}gp.guid.1{','}gp.menu_order.1{','}gp.post_type.1{','}gp.post_mime_type.1{','}gp.comment_count.1{')
}
---rony
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Multi-line literals
Well, there's always { and }, which never gets used because we're
constantly saving them for something in the future.
Rick
On Mon, Oct 31, 2016 at 3:16 PM, Mike Cowlishaw wrote:
>
>
>
> Using /' ... '/ or /" ... "/ for multiline literals
>>
>
> This is not an option, as e. g. say 2 /" 3 "/ 4 is already a valid
> expression
>
>
> Indeed; I was definitely not suggesting a specific syntax, just trying to
> indicate the concept.
>
> Mike
>
>
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
>
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Multi-line literals
Using /' ... '/ or /" ... "/ for multiline literals This is not an option, as e. g. say 2 /" 3 "/ 4 is already a valid expression Indeed; I was definitely not suggesting a specific syntax, just trying to indicate the concept. Mike -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Multi-line literals
> > Using /' ... '/ or /" ... "/ for multiline literals > This is not an option, as e. g. say 2 /" 3 "/ 4 is already a valid expression -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Multi-line literals
On 19.10.2016 15:37, Mike Cowlishaw wrote:
> 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 ...
>
This is a very interesting idea.
Using /' ... '/ or /" ... "/ for multiline literals would help solve the
problem at hand and in
addition allow employing escape characters like \n and the like (and one has
probably to add \/ to
escape the slash, if otherwise the multi-line literal string would be closed
too early).
This also makes it easier to use (unescaped) single and double quotes as many
times as one sees fit
within a string literal, e.g.
str= /" this is a multiline literal using a "double", a ""double double"",
a 'single' or \n\ta
double ''single'' quotes without a problem "/ str= /' this is a multiline
literal using a
"double", a ""double double"", a 'single' or \n\ta double ''single'' quotes
without a problem '/
sql=
Additionally, it becomes possible to have block and line comments unescaped in
such a multi-line
literal, e.g.
say /" this is a multiline literal that allows one to use 'single' or
"double" quotes within the
same string as well as /* comment-like */ text as well as -- double dashes.
\n\tthis was a
newline char followed by a tab char "/
So for example a SQL-statement could be changed from currently (almost
illegible, example extracted
from a post to RexxLA):
sql_cmd = "INSERT INTO wp_posts
(","'ID',","'post_author',", "'post_date',", "'post_date_gmt',",
"'post_content',", "'post_title',","'post_excerpt',", "'post_status',",
"'comment_status',", "'ping_status',", "'post_password',", "'post_name',",
"'to_ping',", "'pinged',", "'post_modified',", "'post_modified_gmt',",
"'post_content_filtered',", "'post_parent',","'guid',", "'menu_order',",
"'post_type',", "'post_mime_type',",
"'comment_count')","VALUES(","'"gp.ID.1"',","'"gp.post_author.1"',","'"gp.post_date.1"',","'"gp.post_date_gmt.1"',","'"gp.post_content.1"',","'"gp.post_title.1"',","'"gp.post_excerpt.1"',","'"gp.post_status.1"',","'"gp.comment_status.1"',","'"gp.ping_status.1"',","'"gp.post_password.1"',","'"gp.post_name.1"',","'"gp.to_ping.1"',","'"gp.pinged.1"',","'"gp.post_modified.1"',","'"gp.post_modified_gmt.1"',","'"gp.post_content_filtered.1"',","'"gp.post_parent.1"',","'"gp.guid.1"',","'"gp.menu_order.1"',","'"gp.post_type.1"',","'"gp.post_mime_type.1"',","'"gp.comment_count.1"'",")"
to a better legible (less error prone) version:
sql_cmd = /" INSERT INTO wp_posts ('ID',
Re: [Oorexx-devel] Multi-line literals
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 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
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
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
> 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 > <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 >> <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 >>> <mailto:object.r...@gmail.com>> wrote:
>
Re: [Oorexx-devel] Multi-line literals
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 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 > <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 >> <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> >>> ___
Re: [Oorexx-devel] Multi-line literals
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 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 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. <mailto:Oorexx-devel@lists.sourceforge.net> sourceforge.net https://lists.sourceforge.net/ <https://lists.sourceforge.net/lists/listinfo/oorexx-devel> 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
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 wrote: > I had a look at the REX folder which mfc has provided at > 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 > 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 > > -- 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
[Oorexx-devel] Multi-line literals
I had a look at the REX folder which mfc has provided at 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 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
