Why is the continuation character (the HYPHEN) needed in some situations *at all* ??

[ThSITC]

Hello there,

    1.) As you all know, I'm working on my own, generalized, Rexx Parser
(any Rexx Dialects)
    2..) As you also most probably do know, I'm (I think) a very
straightforward person ... ;-)
    3.) When I do not know something *personally*, I simply ask!
(Sometimes too soon, before GOOGLE'ing :-()
    4.) When I do get a reply, I think I'm always saying *thank you* ! :-)

Now, I do have an issue which does keep me busy with my own
implemetation of the NetRexx Language:

Why do we need (in NetRexx) the HYPHEN as the continuation character in
the foillowing situations:

a) a line of code is finished by an ordinary OPERATOR (as +, -, *,/,**,
etc)
     ... except the BLANK Operator (of course <grin>)
b) the next line is INITIATED by an ATTRIBUTE (as I call those keywords), as

class abc(myparm1=Rexx, myparm2=int 0)
    uses RexxMsg, RexxFunc

my proposal would be to (quietly) ALLOW those notations (i.e. the
missing HYPHEN) when we
all do agree that this would be a step forward into the right direction,
of course :-)

What do you think?
Thomas.

***************************************************************************************************************
By the way, I do have a great new Joke for you, I did hear 1 week ago in
an Austrian PUB:

What would have happened, on this, our, Earth, when and if ADAM and EVA
would have been *CHINESE* ???

There would BE *NO SINs, at all*, on this, our Earth !!!

Why, you might ask...

Because the Chinese Eva would have eaten the SNAKE, and not the APPLE!
*************************************************************************************************************

[hidden email]
[hidden email]
[hidden email]

PS: I do have, most probably, only one good attribute:

I'm publishing anything *under my own name*,
... and am trying to keep responsible for what I'm doing ... ;-)

Massa Thomas.

Join me on FaceBook, when interested :-)
============================================================================
  --
Thomas Schneider (Founder of www.thsitc.com) Member of the Rexx Languge
Asscociation (www.rexxla.org) Member of the NetRexx Developer's Team
(www.netrexx.org)

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[George Hovey-2]

Thomas,
Doesn't seem to me a step forward at all -- it replaces a simple rule (continue lines with a minus) with a complicated one.  IMO you will waste more time trying to decide if you can omit the minus than by just typing it.

Re joke: I guess you can say that in Austria, but it wouldn't fly in multicultural America.

On Tue, Jan 31, 2012 at 8:45 AM, Thomas Schneider <[hidden email]> wrote:

Hello there,

  1.) As you all know, I'm working on my own, generalized, Rexx Parser (any Rexx Dialects)
  2..) As you also most probably do know, I'm (I think) a very straightforward person ... ;-)
  3.) When I do not know something *personally*, I simply ask! (Sometimes too soon, before GOOGLE'ing :-()
  4.) When I do get a reply, I think I'm always saying *thank you* ! :-)

Now, I do have an issue which does keep me busy with my own implemetation of the NetRexx Language:

Why do we need (in NetRexx) the HYPHEN as the continuation character in the foillowing situations:

a) a line of code is finished by an ordinary OPERATOR (as +, -, *,/,**, etc)
   ... except the BLANK Operator (of course <grin>)
b) the next line is INITIATED by an ATTRIBUTE (as I call those keywords), as

class abc(myparm1=Rexx, myparm2=int 0)
  uses RexxMsg, RexxFunc

my proposal would be to (quietly) ALLOW those notations (i.e. the missing HYPHEN) when we
all do agree that this would be a step forward into the right direction, of course :-)

What do you think?
Thomas.

***************************************************************************************************************
By the way, I do have a great new Joke for you, I did hear 1 week ago in an Austrian PUB:

What would have happened, on this, our, Earth, when and if ADAM and EVA would have been *CHINESE* ???

There would BE *NO SINs, at all*, on this, our Earth !!!

Why, you might ask...

Because the Chinese Eva would have eaten the SNAKE, and not the APPLE!
*************************************************************************************************************

[e-mail]
[e-mail]
[hidden email]

PS: I do have, most probably, only one good attribute:

I'm publishing anything *under my own name*,
... and am trying to keep responsible for what I'm doing ... ;-)

Massa Thomas.

Join me on FaceBook, when interested :-)
============================================================================
 --
Thomas Schneider (Founder of www.thsitc.com) Member of the Rexx Languge Asscociation (www.rexxla.org) Member of the NetRexx Developer's Team (www.netrexx.org)

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Aviatrexx]

I don't know, Tom.  I can think of only a half-dozen reasons off the
top of my head why this should be added to your (rather lengthy) list
of bad ideas:

  1. A single rule is easier to learn than one with lots of exceptions
('i' before 'e', except after 'c', unless you have a weird foreign
scientist for a neighbor who studies ancient species at their height...).

  2. A consistently applied rule is easier to remember than one with
lots of idiosyncratic shortcuts.  If my students learn that they don't
_really_ have to enclose multiple statements following an 'Otherwise"
in a 'Do-End' block, it's not my fault.  More often than not, a
student will learn that there is a shortcut, and proceed to mis-apply it.

  3. Error detection and reporting is easier and more accurate when
there is a consistent rule.

  4. Source code processors (pretty-printers, code analyzers, etc.)
would have a much more difficult syntax to parse.

  5. It's not backwards-compatible.  New code would not compile
correctly with older NetRexx processors, even if it uses no new
capabilities.

  6. The advantage (omitting one character) does not offset the
increased complexity and the problems caused.

Thomas, when precision is important (legal contracts, driving
directions, nuclear power plant operations manuals) you don't find the
use of Twitter spelling or syntax. (OMG! X #3 pmp & drp B4C rods b4 it
bloz!)

Can you offer a single, cogent reason why such a change would be
advantageous?  Or are you just pissing in the punchbowl again?

-Chip-

On 1/31/12 13:45 Thomas Schneider said:

> Why do we need (in NetRexx) the HYPHEN as the continuation character in
> the foillowing situations:
>
> a) a line of code is finished by an ordinary OPERATOR (as +, -, *,/,**,
> etc)
>     ... except the BLANK Operator (of course <grin>)
> b) the next line is INITIATED by an ATTRIBUTE (as I call those
> keywords), as
>
> class abc(myparm1=Rexx, myparm2=int 0)
>    uses RexxMsg, RexxFunc
>
> my proposal would be to (quietly) ALLOW those notations (i.e. the
> missing HYPHEN) when we
> all do agree that this would be a step forward into the right direction,
> of course :-)
>
> What do you think?

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[rickmcguire]

Add that this will also break future upward compatibility, since
adding a subkeyword to an instruction might cause two clauses that
were not originally continued to suddenly be considered a single
clause.  Certain runs counter to all of the care Mike put into ensure
future language changes don't break things.

Rick

On Tue, Jan 31, 2012 at 1:37 PM, Chip Davis <[hidden email]> wrote:

> I don't know, Tom.  I can think of only a half-dozen reasons off the top of
> my head why this should be added to your (rather lengthy) list of bad ideas:
>
>  1. A single rule is easier to learn than one with lots of exceptions ('i'
> before 'e', except after 'c', unless you have a weird foreign scientist for
> a neighbor who studies ancient species at their height...).
>
>  2. A consistently applied rule is easier to remember than one with lots of
> idiosyncratic shortcuts.  If my students learn that they don't _really_ have
> to enclose multiple statements following an 'Otherwise" in a 'Do-End' block,
> it's not my fault.  More often than not, a student will learn that there is
> a shortcut, and proceed to mis-apply it.
>
>  3. Error detection and reporting is easier and more accurate when there is
> a consistent rule.
>
>  4. Source code processors (pretty-printers, code analyzers, etc.) would
> have a much more difficult syntax to parse.
>
>  5. It's not backwards-compatible.  New code would not compile correctly
> with older NetRexx processors, even if it uses no new capabilities.
>
>  6. The advantage (omitting one character) does not offset the increased
> complexity and the problems caused.
>
> Thomas, when precision is important (legal contracts, driving directions,
> nuclear power plant operations manuals) you don't find the use of Twitter
> spelling or syntax. (OMG! X #3 pmp & drp B4C rods b4 it bloz!)
>
> Can you offer a single, cogent reason why such a change would be
> advantageous?  Or are you just pissing in the punchbowl again?
>
> -Chip-
>
>
> On 1/31/12 13:45 Thomas Schneider said:
>>
>> Why do we need (in NetRexx) the HYPHEN as the continuation character in
>> the foillowing situations:
>>
>> a) a line of code is finished by an ordinary OPERATOR (as +, -, *,/,**,
>> etc)
>>    ... except the BLANK Operator (of course <grin>)
>> b) the next line is INITIATED by an ATTRIBUTE (as I call those keywords),
>> as
>>
>> class abc(myparm1=Rexx, myparm2=int 0)
>>   uses RexxMsg, RexxFunc
>>
>> my proposal would be to (quietly) ALLOW those notations (i.e. the missing
>> HYPHEN) when we
>> all do agree that this would be a step forward into the right direction,
>> of course :-)
>>
>> What do you think?
>
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/