Intruducing a SEMANTIC meaning of the keyword THEN ?
Locked
 
|
Hello there,
one of the biggest issues in my worklist is as follows: a) In COBOL; the Keyword THEN, following an IF, is OPTIONAL b) The Keyword THEN, in NetRexx, is REQUIRED c) The NetRexx Language, as I see it, is somewhat A-Symmetrical, as Follows: 1.) Syntax for IF is: IF condition [;] THEN [;] statement 2.) Sytax for WHEN is: WHEN selector [;] THEN [;] statement Historically, what MFC did try, obvioulsy, is to allow the most common notations. My *personal opinion is* that the syntax DEFINITION does NOT take care of the fact, that an implicit (CR=Carriage RETURN) has been ANOTHER semantic meaning than an EXPLICIT *End of Clause* (;) for instance, as another example, the semantic definition of the OTHERWISE and ELSE statements are: ELSE [;] instruction OTHERWISE [;] instruction Now, I do find, and propose, that we shall DEFINE a *sequence of ACTIONS* (Clauses) to be well and uniquely defined. This WILL need to differentiate (SEMANTICALLY) between: if a=b THEN *statement* if a=b THEN statemtent if a=B THEN statement1 ELSE statement (ELSE should be recognized as a KEYWORD here, I'm thinking) and, last, not least: IF a=b [THEN] x=y y=c ELSE d=e k=j END IF (or: ENDIF, spelled as ONE keyword, or even END-IF, as in COBOL) By using a differentiation between the SEMICOLON and the (CR) as the delimier, and the INTRODUCTION of an ENDIF (or END-IF) we can then introduce a difference between a *simple IF* and a *structured IF*. The only necessary actions woul be: a) introduction of an ENDIF statement b) give the imbedded semicolon (') and the Carriage Return (CR) a distincive SEMANTIC. What do you say (except that I'm trying to change the Language). Sincereley, Thomas Schneider. PS: What I do mean is, that: ELSE x=z should have a DIFFERENT semantic as: ELSE x=z b=d ENDIF This would save a LOT of needed DO's and END's, and will be more human readable, at all, I am (personally) thinking.... :-) FORTRAN77 did define the difference between a simple IF and a STRUCTURED IF, by the way, very clealy, as you do certainly know... Have a nice time. Thomas Schneider. 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/
Thomas Schneider, Vienna, Austria (Europe) :-)
www.thsitc.com www.db-123.com |
|
On 8 November 2011 08:00, Thomas Schneider <[hidden email]> wrote: Hello there, 8x------ What do you say (except that I'm trying to change the Language). A.
Can't tweet, won't tweet! _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
Alan
-- Needs more cowbell. |
|
In reply to this post by ThSITC
Thomas,
Across programming languages, there are many syntactic approaches for the definition of "if-then", "if-then-else", "select" and statement grouping constructs. In addition, there are various ways to delimit statements. One of the beauties of Rexx is it's simplicity with respect to these constructs. It is fine the way it is. There is no semantic difference between the carriage return and the semicolon, and to introduce one would add unnecessary complexity. The semicolons following the "then", "else" and "otherwise" keywords are optionally allowed so that the words can be at the end of a line, thus allowing formatting flexibility. I don't see any particular advantages to what you are proposing which are not clearly outweighed by disadvantages. What have I missed? Bill On 11/8/2011 11:00 AM, Thomas Schneider wrote: > Hello there, > one of the biggest issues in my worklist is as follows: > > a) In COBOL; the Keyword THEN, following an IF, is OPTIONAL > b) The Keyword THEN, in NetRexx, is REQUIRED > c) The NetRexx Language, as I see it, is somewhat A-Symmetrical, as > Follows: > > 1.) Syntax for IF is: IF condition [;] THEN [;] statement > 2.) Sytax for WHEN is: WHEN selector [;] THEN [;] statement > > Historically, what MFC did try, obvioulsy, is to allow the most common > notations. > > My *personal opinion is* that the syntax DEFINITION does NOT take care > of the fact, that an implicit (CR=Carriage RETURN) has been ANOTHER > semantic meaning > than an EXPLICIT *End of Clause* (;) > > for instance, as another example, the semantic definition of the > OTHERWISE and ELSE statements are: > > ELSE [;] instruction > OTHERWISE [;] instruction > > Now, I do find, and propose, that we shall DEFINE a *sequence of > ACTIONS* (Clauses) > to be well and uniquely defined. > > This WILL need to differentiate (SEMANTICALLY) between: > > if a=b THEN *statement* > if a=b > THEN statemtent > if a=B THEN statement1 ELSE statement (ELSE should be recognized > as a KEYWORD here, I'm thinking) > > and, last, not least: > > IF a=b [THEN] > x=y > y=c > ELSE > d=e > k=j > END IF (or: ENDIF, spelled as ONE keyword, or even END-IF, as in > COBOL) > > By using a differentiation between the SEMICOLON and the (CR) as the > delimier, > and the INTRODUCTION of an ENDIF (or END-IF) we can then introduce a > difference > between a *simple IF* and a *structured IF*. > > The only necessary actions woul be: > > a) introduction of an ENDIF statement > b) give the imbedded semicolon (') and the Carriage Return (CR) a > distincive SEMANTIC. > > What do you say (except that I'm trying to change the Language). > > Sincereley, > Thomas Schneider. > > PS: What I do mean is, that: > > ELSE x=z > > should have a DIFFERENT semantic as: > > ELSE > x=z > b=d > ENDIF > > This would save a LOT of needed DO's and END's, and will be more human > readable, at all, > I am (personally) thinking.... :-) > > FORTRAN77 did define the difference between a simple IF and a > STRUCTURED IF, by the way, > very clealy, as you do certainly know... > > Have a nice time. > > Thomas Schneider. > > > > 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/ |
Re: Intruducing a SEMANTIC meaning of the keyword THEN ?
|
|
In reply to this post by alansam
Amen!
BOBH On Tue, Nov 8, 2011 at 10:50 AM, Alan Sampson <[hidden email]> wrote:
_______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
In reply to this post by billfen
For someone who was recently complaining about how the syntax of
NetRexx was so different from that of Classic Rexx, I find it hard to believe that you want to change the fundamental syntactic rules of the family of languages. But you buried in the P.S. your true desire: to eliminate all those pesky Do-End blocks. I've got a better idea: Simply change the lexxer to replace 'do' with '{' and 'end' with '}'. No syntactic or semantic changes required. There. Problem solved. :-( -Chip- On 11/8/11 16:57 Bill Fenlason said: > Thomas, > > Across programming languages, there are many syntactic approaches for > the definition of "if-then", "if-then-else", "select" and statement > grouping constructs. In addition, there are various ways to delimit > statements. > > One of the beauties of Rexx is it's simplicity with respect to these > constructs. It is fine the way it is. > > There is no semantic difference between the carriage return and the > semicolon, and to introduce one would add unnecessary complexity. > > The semicolons following the "then", "else" and "otherwise" keywords > are optionally allowed so that the words can be at the end of a line, > thus allowing formatting flexibility. > > I don't see any particular advantages to what you are proposing which > are not clearly outweighed by disadvantages. What have I missed? > > Bill > > On 11/8/2011 11:00 AM, Thomas Schneider wrote: >> Hello there, >> one of the biggest issues in my worklist is as follows: >> >> a) In COBOL; the Keyword THEN, following an IF, is OPTIONAL >> b) The Keyword THEN, in NetRexx, is REQUIRED >> c) The NetRexx Language, as I see it, is somewhat A-Symmetrical, as >> Follows: >> >> 1.) Syntax for IF is: IF condition [;] THEN [;] statement >> 2.) Sytax for WHEN is: WHEN selector [;] THEN [;] statement >> >> Historically, what MFC did try, obvioulsy, is to allow the most common >> notations. >> >> My *personal opinion is* that the syntax DEFINITION does NOT take care >> of the fact, that an implicit (CR=Carriage RETURN) has been ANOTHER >> semantic meaning >> than an EXPLICIT *End of Clause* (;) >> >> for instance, as another example, the semantic definition of the >> OTHERWISE and ELSE statements are: >> >> ELSE [;] instruction >> OTHERWISE [;] instruction >> >> Now, I do find, and propose, that we shall DEFINE a *sequence of >> ACTIONS* (Clauses) >> to be well and uniquely defined. >> >> This WILL need to differentiate (SEMANTICALLY) between: >> >> if a=b THEN *statement* >> if a=b >> THEN statemtent >> if a=B THEN statement1 ELSE statement (ELSE should be recognized >> as a KEYWORD here, I'm thinking) >> >> and, last, not least: >> >> IF a=b [THEN] >> x=y >> y=c >> ELSE >> d=e >> k=j >> END IF (or: ENDIF, spelled as ONE keyword, or even END-IF, as in >> COBOL) >> >> By using a differentiation between the SEMICOLON and the (CR) as the >> delimier, >> and the INTRODUCTION of an ENDIF (or END-IF) we can then introduce a >> difference >> between a *simple IF* and a *structured IF*. >> >> The only necessary actions woul be: >> >> a) introduction of an ENDIF statement >> b) give the imbedded semicolon (') and the Carriage Return (CR) a >> distincive SEMANTIC. >> >> What do you say (except that I'm trying to change the Language). >> >> Sincereley, >> Thomas Schneider. >> >> PS: What I do mean is, that: >> >> ELSE x=z >> >> should have a DIFFERENT semantic as: >> >> ELSE >> x=z >> b=d >> ENDIF >> >> This would save a LOT of needed DO's and END's, and will be more human >> readable, at all, >> I am (personally) thinking.... :-) >> >> FORTRAN77 did define the difference between a simple IF and a >> STRUCTURED IF, by the way, >> very clealy, as you do certainly know... >> >> Have a nice time. >> >> Thomas Schneider. >> >> >> >> 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/ > > _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
In reply to this post by alansam
Hello ALAN Sampson, *and all* This reply is ONLY *to assure you* that my proposed Syntax/Semantics *enhancements* (when they are enhancements) *will NOT beak* any existing NetRexx/Rexx/ooRexx/Regina program. :-) As you, and all, for sure, do know: I'm saying, that UPWARDS Compatibility (of any language) is the most important issue ! I did ONLY raise this point, because I'm currently testing some bits... ... and while testing it, it did came to my mind ... When you like, I could enter a FORMAL SPEC of those (proposed) enhancements, here & there.... :-) +i+ nevertheless would like to ask: 1.) Why (the hell) could a SEQUENCE of ACTIONS follow: - catch - finally -otherwise *and NOT*: -when ??????????????????? IF is more complicated, I do agree, due to (historical) reasons, I do have the (personal) feeling.... Thomas. PS: Why do I need a THEN after a WHEN??? ================================================================================== Am 08.11.2011 17:50, schrieb Alan Sampson:
--
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/
Thomas Schneider, Vienna, Austria (Europe) :-)
www.thsitc.com www.db-123.com |
|
|
In reply to this post by billfen
Hello Bill,
thanks for clarification :-) But *what is* with a NEWBIE writing somehing a: IF a=b THEN x=y ELSE z=v in the Rexx Family of Languages? He is missing the SEMICOLON after x=y, and thus ELSE does become 'ELSE' (in classic Rexx and ooRexx), not so in NetRexx, however ... Should'nt the compiler say: 'End of statement/instruction required before Verb ELSE' *instead of* 'unknown Variable' ?? Thomas. =================================================================================================== Am 08.11.2011 17:57, schrieb Bill Fenlason: > Thomas, > > Across programming languages, there are many syntactic approaches for > the definition of "if-then", "if-then-else", "select" and statement > grouping constructs. In addition, there are various ways to delimit > statements. > > One of the beauties of Rexx is it's simplicity with respect to these > constructs. It is fine the way it is. > > There is no semantic difference between the carriage return and the > semicolon, and to introduce one would add unnecessary complexity. > > The semicolons following the "then", "else" and "otherwise" keywords > are optionally allowed so that the words can be at the end of a line, > thus allowing formatting flexibility. > > I don't see any particular advantages to what you are proposing which > are not clearly outweighed by disadvantages. What have I missed? > > Bill > > On 11/8/2011 11:00 AM, Thomas Schneider wrote: >> Hello there, >> one of the biggest issues in my worklist is as follows: >> >> a) In COBOL; the Keyword THEN, following an IF, is OPTIONAL >> b) The Keyword THEN, in NetRexx, is REQUIRED >> c) The NetRexx Language, as I see it, is somewhat A-Symmetrical, as >> Follows: >> >> 1.) Syntax for IF is: IF condition [;] THEN [;] statement >> 2.) Sytax for WHEN is: WHEN selector [;] THEN [;] statement >> >> Historically, what MFC did try, obvioulsy, is to allow the most >> common notations. >> >> My *personal opinion is* that the syntax DEFINITION does NOT take care >> of the fact, that an implicit (CR=Carriage RETURN) has been ANOTHER >> semantic meaning >> than an EXPLICIT *End of Clause* (;) >> >> for instance, as another example, the semantic definition of the >> OTHERWISE and ELSE statements are: >> >> ELSE [;] instruction >> OTHERWISE [;] instruction >> >> Now, I do find, and propose, that we shall DEFINE a *sequence of >> ACTIONS* (Clauses) >> to be well and uniquely defined. >> >> This WILL need to differentiate (SEMANTICALLY) between: >> >> if a=b THEN *statement* >> if a=b >> THEN statemtent >> if a=B THEN statement1 ELSE statement (ELSE should be recognized >> as a KEYWORD here, I'm thinking) >> >> and, last, not least: >> >> IF a=b [THEN] >> x=y >> y=c >> ELSE >> d=e >> k=j >> END IF (or: ENDIF, spelled as ONE keyword, or even END-IF, as in >> COBOL) >> >> By using a differentiation between the SEMICOLON and the (CR) as the >> delimier, >> and the INTRODUCTION of an ENDIF (or END-IF) we can then introduce a >> difference >> between a *simple IF* and a *structured IF*. >> >> The only necessary actions woul be: >> >> a) introduction of an ENDIF statement >> b) give the imbedded semicolon (') and the Carriage Return (CR) a >> distincive SEMANTIC. >> >> What do you say (except that I'm trying to change the Language). >> >> Sincereley, >> Thomas Schneider. >> >> PS: What I do mean is, that: >> >> ELSE x=z >> >> should have a DIFFERENT semantic as: >> >> ELSE >> x=z >> b=d >> ENDIF >> >> This would save a LOT of needed DO's and END's, and will be more >> human readable, at all, >> I am (personally) thinking.... :-) >> >> FORTRAN77 did define the difference between a simple IF and a >> STRUCTURED IF, by the way, >> very clealy, as you do certainly know... >> >> Have a nice time. >> >> Thomas Schneider. >> >> >> >> 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/ > > -- 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/
Thomas Schneider, Vienna, Austria (Europe) :-)
www.thsitc.com www.db-123.com |
|
|
In reply to this post by Aviatrexx
Hi Chip, already done :-)
You might define '{'=DO *and* '}'=END in Rey.opers for my ReyC .... Let me state my point: 1.) I'm proposing *ideas here* 2.) I am NOT saying that NetRexx has pitfalls. 3.) I'm thinking (maybe too loud :-) of possible improvements. FULL STOP from my side.... Thomas. PS: At least, my approach does allow me to deine that '~' is used in Denmark as the NOT Operator... And '!' as the '|' operator in GERMAN RExx.... Capisci? Thomas. PPS: I thought I will initiate a discussion... :-( ============================================================================== Am 08.11.2011 18:51, schrieb Chip Davis: > For someone who was recently complaining about how the syntax of > NetRexx was so different from that of Classic Rexx, I find it hard to > believe that you want to change the fundamental syntactic rules of the > family of languages. > > But you buried in the P.S. your true desire: to eliminate all those > pesky Do-End blocks. > > I've got a better idea: Simply change the lexxer to replace 'do' with > '{' and 'end' with '}'. No syntactic or semantic changes required. > > There. Problem solved. :-( > > -Chip- > > On 11/8/11 16:57 Bill Fenlason said: >> Thomas, >> >> Across programming languages, there are many syntactic approaches for >> the definition of "if-then", "if-then-else", "select" and statement >> grouping constructs. In addition, there are various ways to delimit >> statements. >> >> One of the beauties of Rexx is it's simplicity with respect to these >> constructs. It is fine the way it is. >> >> There is no semantic difference between the carriage return and the >> semicolon, and to introduce one would add unnecessary complexity. >> >> The semicolons following the "then", "else" and "otherwise" keywords >> are optionally allowed so that the words can be at the end of a line, >> thus allowing formatting flexibility. >> >> I don't see any particular advantages to what you are proposing which >> are not clearly outweighed by disadvantages. What have I missed? >> >> Bill >> >> On 11/8/2011 11:00 AM, Thomas Schneider wrote: >>> Hello there, >>> one of the biggest issues in my worklist is as follows: >>> >>> a) In COBOL; the Keyword THEN, following an IF, is OPTIONAL >>> b) The Keyword THEN, in NetRexx, is REQUIRED >>> c) The NetRexx Language, as I see it, is somewhat A-Symmetrical, as >>> Follows: >>> >>> 1.) Syntax for IF is: IF condition [;] THEN [;] statement >>> 2.) Sytax for WHEN is: WHEN selector [;] THEN [;] statement >>> >>> Historically, what MFC did try, obvioulsy, is to allow the most >>> common notations. >>> >>> My *personal opinion is* that the syntax DEFINITION does NOT take care >>> of the fact, that an implicit (CR=Carriage RETURN) has been ANOTHER >>> semantic meaning >>> than an EXPLICIT *End of Clause* (;) >>> >>> for instance, as another example, the semantic definition of the >>> OTHERWISE and ELSE statements are: >>> >>> ELSE [;] instruction >>> OTHERWISE [;] instruction >>> >>> Now, I do find, and propose, that we shall DEFINE a *sequence of >>> ACTIONS* (Clauses) >>> to be well and uniquely defined. >>> >>> This WILL need to differentiate (SEMANTICALLY) between: >>> >>> if a=b THEN *statement* >>> if a=b >>> THEN statemtent >>> if a=B THEN statement1 ELSE statement (ELSE should be >>> recognized as a KEYWORD here, I'm thinking) >>> >>> and, last, not least: >>> >>> IF a=b [THEN] >>> x=y >>> y=c >>> ELSE >>> d=e >>> k=j >>> END IF (or: ENDIF, spelled as ONE keyword, or even END-IF, as in >>> COBOL) >>> >>> By using a differentiation between the SEMICOLON and the (CR) as the >>> delimier, >>> and the INTRODUCTION of an ENDIF (or END-IF) we can then introduce a >>> difference >>> between a *simple IF* and a *structured IF*. >>> >>> The only necessary actions woul be: >>> >>> a) introduction of an ENDIF statement >>> b) give the imbedded semicolon (') and the Carriage Return (CR) a >>> distincive SEMANTIC. >>> >>> What do you say (except that I'm trying to change the Language). >>> >>> Sincereley, >>> Thomas Schneider. >>> >>> PS: What I do mean is, that: >>> >>> ELSE x=z >>> >>> should have a DIFFERENT semantic as: >>> >>> ELSE >>> x=z >>> b=d >>> ENDIF >>> >>> This would save a LOT of needed DO's and END's, and will be more >>> human readable, at all, >>> I am (personally) thinking.... :-) >>> >>> FORTRAN77 did define the difference between a simple IF and a >>> STRUCTURED IF, by the way, >>> very clealy, as you do certainly know... >>> >>> Have a nice time. >>> >>> Thomas Schneider. >>> >>> >>> >>> 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/ >> >> > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ > > -- 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/
Thomas Schneider, Vienna, Austria (Europe) :-)
www.thsitc.com www.db-123.com |
|
|
In reply to this post by ThSITC
On 8 November 2011 10:25, Thomas Schneider <[hidden email]> wrote: -- Hello Bill, How would your proposed change handle the following NetRexx program? /* NetRexx */
options replace format comments java crossref symbols nobinary a = 'a'; b = 'a' y = a; z = b
v = 'a . a' ELSE = '.' IF a=b THEN x=y ELSE z=v
say x FYI; The program compiles, works and displays a result of 1 which is what I expected.
A. Can't tweet, won't tweet! _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
Alan
-- Needs more cowbell. |
Re: Intruducing a SEMANTIC meaning of the keyword THEN ?
|
|
In reply to this post by ThSITC
Thomas,
I'll chance joining you on the scaffold by raising a small voice in support. I, too, spent one of my lives writing FORTRAN, and its notion of a conditional statement: If statement(s) [Else If -- repeated 0 or more times statement(s)] [Else -- repeated 0 or 1 times statement(s)] End If strikes me as so simple, logical, clear, readable, and fool-proof that it's a mystery it hasn't swept the programming world. It does exactly what it appears to do, and covers everything one would want to do in a conditional statement. NetRexx's style (which seems the same as C's), if expression[;] then[;] instruction [else[;] instruction] has at least two problems. With it, one gets the 'Else If' effect by actually writing two if's which appear to be an 'Else If' (the example is from 'H&S' - Harbison and Steele, "C - A Reference Manual): If (expression1) statement1 else if (expression2) statement2 else if (expression3) statement3 ... else statementn This, according to H&S, suffers from "The Dangling-Else Problem": "An ambiguity arises because a conditional statement may contain another conditional statement. In some situations it may not be apparent to which of several conditional statements an 'else' might belong. The ambiguity is resolved in an arbitrary but customary way: an 'else' part is always assumed to belong to the innermost 'if' statement possible. Have you never been bitten by this? Correct me if I'm wrong, but NetRexx seems to suffer from this very problem: a programmer must follow a "custom" -- not checked by the compiler -- in order to correctly parse his own program.A second defect, IMO, arises from the fact that the construct operates on single statements. [Note that the FORTRAN version does not.] Of course, if there are multiple statements one simply encloses them in Do...End. What's the problem? I found out while working for a company that produces highway traffic control software. All developers were required to put a fraction of their time into maintaining the company's flagship product. It consisted of 750K lines of C produced in the "Guru Era" before software engineering. Its developers were long gone (put to death, some said, and buried along with all documentation in a secret location in order to thwart industrial espionage). Here is a construct we saw frequently if (condition) statement1 statement2 Often it could be deduced that the author expected 'statement2' to be executed only when 'condition' was true. That person was not necessarily the original author; it may well have been a maintainer "fixing" a bug that required patching multiple places in the program -- in some cases, our maintenance efforts made the program buggier! Why didn't we just do it right? Partly because we were working under considerable pressure and partly because the language didn't give us any help in avoiding the situation. P.S. When you hear the blade drop, try to blink rapidly. Your effort may be of some small value to science. ;) Regards, George On Tue, Nov 8, 2011 at 11:00 AM, Thomas Schneider <[hidden email]> wrote: > Hello there, > one of the biggest issues in my worklist is as follows: > > a) In COBOL; the Keyword THEN, following an IF, is OPTIONAL > b) The Keyword THEN, in NetRexx, is REQUIRED > c) The NetRexx Language, as I see it, is somewhat A-Symmetrical, as Follows: > > 1.) Syntax for IF is: IF condition [;] THEN [;] statement > 2.) Sytax for WHEN is: WHEN selector [;] THEN [;] statement > > Historically, what MFC did try, obvioulsy, is to allow the most common > notations. > > My *personal opinion is* that the syntax DEFINITION does NOT take care > of the fact, that an implicit (CR=Carriage RETURN) has been ANOTHER semantic > meaning > than an EXPLICIT *End of Clause* (;) > > for instance, as another example, the semantic definition of the OTHERWISE > and ELSE statements are: > > ELSE [;] instruction > OTHERWISE [;] instruction > > Now, I do find, and propose, that we shall DEFINE a *sequence of ACTIONS* > (Clauses) > to be well and uniquely defined. > > This WILL need to differentiate (SEMANTICALLY) between: > > if a=b THEN *statement* > if a=b > THEN statemtent > if a=B THEN statement1 ELSE statement (ELSE should be recognized as a > KEYWORD here, I'm thinking) > > and, last, not least: > > IF a=b [THEN] > x=y > y=c > ELSE > d=e > k=j > END IF (or: ENDIF, spelled as ONE keyword, or even END-IF, as in COBOL) > By using a differentiation between the SEMICOLON and the (CR) as the > delimier, > and the INTRODUCTION of an ENDIF (or END-IF) we can then introduce a > difference > between a *simple IF* and a *structured IF*. > > The only necessary actions woul be: > > a) introduction of an ENDIF statement > b) give the imbedded semicolon (') and the Carriage Return (CR) a > distincive SEMANTIC. > > What do you say (except that I'm trying to change the Language). > > Sincereley, > Thomas Schneider. > > PS: What I do mean is, that: > > ELSE x=z > > should have a DIFFERENT semantic as: > > ELSE > x=z > b=d > ENDIF > > This would save a LOT of needed DO's and END's, and will be more human > readable, at all, > I am (personally) thinking.... :-) > > FORTRAN77 did define the difference between a simple IF and a STRUCTURED IF, > by the way, > very clealy, as you do certainly know... > > Have a nice time. > > Thomas Schneider. > > > > 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/ |
|
|
In reply to this post by ThSITC
Thomas,
In NetRexx, the the default assignment of a variable to it's name is not done, and ELSE does not become "else". It is treated as a dynamic variable, evaluated at execution time. NetRexx and classic REXX are different languages, with different approaches to variable defaults. In both languages, IF a=b THEN x=y ELSE z = v is equivalent to IF a=b THEN x=y ; ELSE z=v Either a semicolon or the end of line must be used to terminate the instruction in the THEN clause. Are you just complaining about the wording of the NetRexx error message? Bill On 11/8/2011 1:25 PM, Thomas Schneider wrote: > Hello Bill, > thanks for clarification :-) > > But *what is* with a NEWBIE writing somehing a: > > IF a=b THEN x=y ELSE z=v > > in the Rexx Family of Languages? > > He is missing the SEMICOLON after x=y, and thus ELSE does become > 'ELSE' (in classic Rexx and ooRexx), not so in NetRexx, > however ... > > Should'nt the compiler say: 'End of statement/instruction required > before Verb ELSE' > > *instead of* > > 'unknown Variable' ?? > > Thomas. > =================================================================================================== > > > Am 08.11.2011 17:57, schrieb Bill Fenlason: >> Thomas, >> >> Across programming languages, there are many syntactic approaches for >> the definition of "if-then", "if-then-else", "select" and statement >> grouping constructs. In addition, there are various ways to delimit >> statements. >> >> One of the beauties of Rexx is it's simplicity with respect to these >> constructs. It is fine the way it is. >> >> There is no semantic difference between the carriage return and the >> semicolon, and to introduce one would add unnecessary complexity. >> >> The semicolons following the "then", "else" and "otherwise" keywords >> are optionally allowed so that the words can be at the end of a line, >> thus allowing formatting flexibility. >> >> I don't see any particular advantages to what you are proposing which >> are not clearly outweighed by disadvantages. What have I missed? >> >> Bill >> >> On 11/8/2011 11:00 AM, Thomas Schneider wrote: >>> Hello there, >>> one of the biggest issues in my worklist is as follows: >>> >>> a) In COBOL; the Keyword THEN, following an IF, is OPTIONAL >>> b) The Keyword THEN, in NetRexx, is REQUIRED >>> c) The NetRexx Language, as I see it, is somewhat A-Symmetrical, as >>> Follows: >>> >>> 1.) Syntax for IF is: IF condition [;] THEN [;] statement >>> 2.) Sytax for WHEN is: WHEN selector [;] THEN [;] statement >>> >>> Historically, what MFC did try, obvioulsy, is to allow the most >>> common notations. >>> >>> My *personal opinion is* that the syntax DEFINITION does NOT take care >>> of the fact, that an implicit (CR=Carriage RETURN) has been ANOTHER >>> semantic meaning >>> than an EXPLICIT *End of Clause* (;) >>> >>> for instance, as another example, the semantic definition of the >>> OTHERWISE and ELSE statements are: >>> >>> ELSE [;] instruction >>> OTHERWISE [;] instruction >>> >>> Now, I do find, and propose, that we shall DEFINE a *sequence of >>> ACTIONS* (Clauses) >>> to be well and uniquely defined. >>> >>> This WILL need to differentiate (SEMANTICALLY) between: >>> >>> if a=b THEN *statement* >>> if a=b >>> THEN statemtent >>> if a=B THEN statement1 ELSE statement (ELSE should be >>> recognized as a KEYWORD here, I'm thinking) >>> >>> and, last, not least: >>> >>> IF a=b [THEN] >>> x=y >>> y=c >>> ELSE >>> d=e >>> k=j >>> END IF (or: ENDIF, spelled as ONE keyword, or even END-IF, as in >>> COBOL) >>> >>> By using a differentiation between the SEMICOLON and the (CR) as the >>> delimier, >>> and the INTRODUCTION of an ENDIF (or END-IF) we can then introduce a >>> difference >>> between a *simple IF* and a *structured IF*. >>> >>> The only necessary actions woul be: >>> >>> a) introduction of an ENDIF statement >>> b) give the imbedded semicolon (') and the Carriage Return (CR) a >>> distincive SEMANTIC. >>> >>> What do you say (except that I'm trying to change the Language). >>> >>> Sincereley, >>> Thomas Schneider. >>> >>> PS: What I do mean is, that: >>> >>> ELSE x=z >>> >>> should have a DIFFERENT semantic as: >>> >>> ELSE >>> x=z >>> b=d >>> ENDIF >>> >>> This would save a LOT of needed DO's and END's, and will be more >>> human readable, at all, >>> I am (personally) thinking.... :-) >>> >>> FORTRAN77 did define the difference between a simple IF and a >>> STRUCTURED IF, by the way, >>> very clealy, as you do certainly know... >>> >>> Have a nice time. >>> >>> Thomas Schneider. >>> >>> >>> >>> 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/ >> >> > > _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
In reply to this post by alansam
Warning: Reserved Verb 'ELSE' illegally used as Variable Name!
Thomas. ======================================================================== PS: Am 08.11.2011 19:52, schrieb Alan Sampson:
--
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/
Thomas Schneider, Vienna, Austria (Europe) :-)
www.thsitc.com www.db-123.com |
|
|
In reply to this post by George Hovey-2
Hi George:
(1) thanks for support on this (my last) issue :-) (2) I do personally think that FORTRANs 77 and also FORTRANs 92 definition of the IF STATEMENT is the simple IF, three branch IF (IF (integer) label1, label2,label3), which we don't need in NetRexx), and the so-called *structured IF* are essential, however: What we DO need, obviously *even in NetRexx*, is: (a) The definition of the so called *ELSE IF* clause (as a SINGLE Clause) (b) the definition (*and only the definiton* of a proper ENDIF. (3) a *clear Definition* of a *Sequence of ACTIONS* (statement, Instructions, ACTIONS, as I call them) What we ONLY would need is an ENDIF (or, and, END-IF, ENDIF) to TERMINATE the structured IF (*and/or* the last ELSE) There is NO reason, at all, why the WHEN-statement cannot be DEFINED as: WHEN value-selector [THEN DO] ... dependent actions ... [END WHEN] OTHERWISE .. dependent ACTIONS END SELECT What I' here proposing is to allow the STRUCTURE keyowrd (e.g. IF, LOOP, DO, and also the method name) to be appended after the END key-word. This will also allow for more accurate syntax and semtaic checking, when wanted, and also might improve readibility of the source. I used to work with some languages, where the proper END xxxxx statement even does CLOSE all yet unended constructs (implicitely) For NetRexx, I would also suggest something as: END method-name which, in turn would allow NESTED (innner) methods) as somebody (Kermit Kiser, I think, did propose) We should also support END class-name (I do personally think) The current ONLY open issue to introduce this would be the requiement of ENDIF (may be spelled END-IF, ENDIF, END--IF..., by the way, I am proposing!) ************************************************************************************************************************************* *THEN* : we could save a lot of THEN DO ... END ************************************************************************************************************************************* and, *THEN*, a NetRexx Source program wil be: a) shorter b) more HUMAN Readable :-) ========================================================================================= Kind regards from Vienna, Thomas. ========================================================================================= am 08.11.2011 19:54, schrieb George Hovey: Thomas, --
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/
Thomas Schneider, Vienna, Austria (Europe) :-)
www.thsitc.com www.db-123.com |
|
|
In reply to this post by ThSITC
Thomas,
NetRexx has no reserved words. In NetRexx ELSE can be an overloaded statement keyword (method) as well as a variable name. There was a long discussion about the dynamic nature of NetRexx some time ago. I'm in the camp which prefers keywords to be treated as reserved as an option, but maintaining keyword extensibility is high on MFC's priority list. As he says in the language doc: "Keywords in Rexx are not globally reserved but are recognized only in context. This language attribute has allowed the language to be extended substantially over the years without invalidating existing programs. Even so, some areas of Rexx have proved difficult to extend – for example, keywords are reserved within instructions such as do. Therefore, the design for NetRexx takes the concept of keyword safety even further than in Rexx, and also improves extensibility in other areas." I think a required (not optional) initial comment to specify the language dialect and version (e.g. " /* NetRexx 4 " ... " */ " as initial tokens) would be a better solution for keyword extensibility. That is the way HTML, etc. does it (via doctype). But that's "above my pay grade" :) Bill On 11/8/2011 2:15 PM, Thomas Schneider wrote: Warning: Reserved Verb 'ELSE' illegally used as Variable Name! On 11/8/2011 2:32 PM, Thomas Schneider wrote: Long time ago, I wrote a simple NetRexx method: _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
In reply to this post by billfen
Hi Bill:
What I'm Saying, is, that, in HUMAN READING: IF a=b THEN x=y ELSE z=v ** should be accepted** (one of the most common PITFALLS, I'm recoginzing, from samples) IF a=b THEN x=y ELSE z = v *Is equivalent to* IF a=b THEN x=y ELSE z = v ********but *************** IF a=b THEN x=y ELSE z = v v=123456 ENDIF ** should be allowed** ** as well as *** IF a=b x=y z1=z3 ELSE z = v ** as well as** IF a=b x=y z1=z3 ELSE z = v k1=z+v END IF ** as well as ** IF a=b x=y z1=z3 ELSE IF a=c k=13 j=12345.678 ELSE z = v k1=z+v END IF Note that the last case is *semantically* equivalent to a NetRexx SELECT statement, anyway! SELECT WHEN a=b THEN DO x=y z1=z3 END--WHEN WHEN a=c THEN DO k=13 j=12345.678 END--WHEN OTHERWISE z = v k1=z+v END SELECT (proposed enhancement: in NetRexx, you will have to write END--SELECT) There *is* a semantic difference BETWEEN a LINE Break (CR) *and* an imbedded ';' *And*, there is an un-necessary Language A-Symmetry for SEQUENCES of Actions (Instructions) ! :-( (*** To many *unnecessary* THEN DO's and matching END's required :-( )) Full Stop. The current SYNTAX of NetRexx has NOT to be changed. But the SEMANTIC meaning of a ';' and a (CR) ... the only thing we need is an END IF in the latter case !!! Yust my 2 cents, to grow up this discussion For reference, please do read up the FORTRAN 77 *STRUCTURED IF STATEMENT* Google it, or just ask! Sincerely, Thomas Schneider. ======================================================================================= Am 08.11.2011 20:05, schrieb Bill Fenlason: > Thomas, > > In NetRexx, the the default assignment of a variable to it's name is > not done, and ELSE does not become "else". It is treated as a dynamic > variable, evaluated at execution time. > > NetRexx and classic REXX are different languages, with different > approaches to variable defaults. > > In both languages, > > IF a=b THEN x=y > ELSE z = v > > is equivalent to > > IF a=b THEN x=y ; ELSE z=v > > Either a semicolon or the end of line must be used to terminate the > instruction in the THEN clause. > > Are you just complaining about the wording of the NetRexx error message? > > Bill > > On 11/8/2011 1:25 PM, Thomas Schneider wrote: >> Hello Bill, >> thanks for clarification :-) >> >> But *what is* with a NEWBIE writing somehing a: >> >> IF a=b THEN x=y ELSE z=v >> >> in the Rexx Family of Languages? >> >> He is missing the SEMICOLON after x=y, and thus ELSE does become >> 'ELSE' (in classic Rexx and ooRexx), not so in NetRexx, >> however ... >> >> Should'nt the compiler say: 'End of statement/instruction required >> before Verb ELSE' >> >> *instead of* >> >> 'unknown Variable' ?? >> >> Thomas. >> =================================================================================================== >> >> >> Am 08.11.2011 17:57, schrieb Bill Fenlason: >>> Thomas, >>> >>> Across programming languages, there are many syntactic approaches >>> for the definition of "if-then", "if-then-else", "select" and >>> statement grouping constructs. In addition, there are various ways >>> to delimit statements. >>> >>> One of the beauties of Rexx is it's simplicity with respect to these >>> constructs. It is fine the way it is. >>> >>> There is no semantic difference between the carriage return and the >>> semicolon, and to introduce one would add unnecessary complexity. >>> >>> The semicolons following the "then", "else" and "otherwise" >>> keywords are optionally allowed so that the words can be at the end >>> of a line, thus allowing formatting flexibility. >>> >>> I don't see any particular advantages to what you are proposing >>> which are not clearly outweighed by disadvantages. What have I missed? >>> >>> Bill >>> >>> On 11/8/2011 11:00 AM, Thomas Schneider wrote: >>>> Hello there, >>>> one of the biggest issues in my worklist is as follows: >>>> >>>> a) In COBOL; the Keyword THEN, following an IF, is OPTIONAL >>>> b) The Keyword THEN, in NetRexx, is REQUIRED >>>> c) The NetRexx Language, as I see it, is somewhat A-Symmetrical, as >>>> Follows: >>>> >>>> 1.) Syntax for IF is: IF condition [;] THEN [;] statement >>>> 2.) Sytax for WHEN is: WHEN selector [;] THEN [;] statement >>>> >>>> Historically, what MFC did try, obvioulsy, is to allow the most >>>> common notations. >>>> >>>> My *personal opinion is* that the syntax DEFINITION does NOT take care >>>> of the fact, that an implicit (CR=Carriage RETURN) has been ANOTHER >>>> semantic meaning >>>> than an EXPLICIT *End of Clause* (;) >>>> >>>> for instance, as another example, the semantic definition of the >>>> OTHERWISE and ELSE statements are: >>>> >>>> ELSE [;] instruction >>>> OTHERWISE [;] instruction >>>> >>>> Now, I do find, and propose, that we shall DEFINE a *sequence of >>>> ACTIONS* (Clauses) >>>> to be well and uniquely defined. >>>> >>>> This WILL need to differentiate (SEMANTICALLY) between: >>>> >>>> if a=b THEN *statement* >>>> if a=b >>>> THEN statemtent >>>> if a=B THEN statement1 ELSE statement (ELSE should be >>>> recognized as a KEYWORD here, I'm thinking) >>>> >>>> and, last, not least: >>>> >>>> IF a=b [THEN] >>>> x=y >>>> y=c >>>> ELSE >>>> d=e >>>> k=j >>>> END IF (or: ENDIF, spelled as ONE keyword, or even END-IF, as in >>>> COBOL) >>>> >>>> By using a differentiation between the SEMICOLON and the (CR) as >>>> the delimier, >>>> and the INTRODUCTION of an ENDIF (or END-IF) we can then introduce >>>> a difference >>>> between a *simple IF* and a *structured IF*. >>>> >>>> The only necessary actions woul be: >>>> >>>> a) introduction of an ENDIF statement >>>> b) give the imbedded semicolon (') and the Carriage Return (CR) >>>> a distincive SEMANTIC. >>>> >>>> What do you say (except that I'm trying to change the Language). >>>> >>>> Sincereley, >>>> Thomas Schneider. >>>> >>>> PS: What I do mean is, that: >>>> >>>> ELSE x=z >>>> >>>> should have a DIFFERENT semantic as: >>>> >>>> ELSE >>>> x=z >>>> b=d >>>> ENDIF >>>> >>>> This would save a LOT of needed DO's and END's, and will be more >>>> human readable, at all, >>>> I am (personally) thinking.... :-) >>>> >>>> FORTRAN77 did define the difference between a simple IF and a >>>> STRUCTURED IF, by the way, >>>> very clealy, as you do certainly know... >>>> >>>> Have a nice time. >>>> >>>> Thomas Schneider. >>>> >>>> >>>> >>>> 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/ >>> >>> >> >> > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ > > -- 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/
Thomas Schneider, Vienna, Austria (Europe) :-)
www.thsitc.com www.db-123.com |
|
|
On 8 November 2011 12:28, Thomas Schneider <[hidden email]> wrote: Hi Bill: ELSE = '.' a = 'a'; b = 'a'
y = a; z = b v = a ELSE b
IF a=b THEN x=y ELSE z=v
Your suggestion will break that program for very little benefit! What happens to upward compatibility? A.
Can't tweet, won't tweet! _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
Alan
-- Needs more cowbell. |
|
|
In reply to this post by billfen
Hi Bill,
my implementation *does have* reserver words (unless ths symbol is used in n aassignment). Full Stop. Thomas. PS: Still playing around about the advantages &/ pitfalls of my approach. Sorry to say. ======================================================================================== Am 08.11.2011 21:13, schrieb Bill Fenlason: Thomas, --
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/
Thomas Schneider, Vienna, Austria (Europe) :-)
www.thsitc.com www.db-123.com |
|
|
In reply to this post by ThSITC
On 11/8/2011 3:28 PM, Thomas Schneider wrote:
> Hi Bill: ... > > For reference, please do read up the FORTRAN 77 *STRUCTURED IF STATEMENT* > > Google it, or just ask! > > Sincerely, Thomas Schneider. > ================================================================ Thomas, I was writing FORTRAN programs almost 50 years ago, and implementing a FORTRAN 77 compiler (at IBM) 30 years ago. Don't try to lecture me about it - I find that offensive! The bottom line is that there is no need for what you are proposing. While you may not like the convention of surrounding a group of statements with "do... end" to make a unit for a THEN or ELSE clause, it is more than sufficient. There is no need for ELSEIF or ENDIF or distinguishing " ; " from CR. While interesting, it is not necessarily a "better mousetrap". Of course, you are free to implement whatever you want (for syntactic sugar) in your own version of NetRexx. But it might be better if you wait until you have programmed, debugged and thoroughly tested these ideas before suggesting them as enhancements to "The" NetRexx language. Bill _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
Hi Bill, and all,
OK! :-) I will proceed as you (Bill) suggested! ... and: sorry foir the interrupton:) Thomas PS: Do you know Don Quichotte ? I'm more and mor feeling as ´this guy (fighting against windmills) ... But maybe(!) I'll survive. Cheers. Thomas.# _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
Thomas Schneider, Vienna, Austria (Europe) :-)
www.thsitc.com www.db-123.com |
«
Return to ibm-netrexx
|
1 view|%1 views
| Free forum by Nabble | Edit this page |