properties instruction
Locked
 
|
Experimentation with Bill Finlason's excellent and very promising Eclipse plugin for NetRexx yields a question which one is right: the translator or the documentation. This is because I tend to use a 'properties' statement on its own when I am in a hurry, and let it default to inheritable. "Why use a properties statement at all then?", is a legitimate question, to which I do not know the answer.
Anyway, a 'properties' followed by a newline causes an error flagged by the plugin's grammar. Now Bill reminded me of page 111 in nrl2, where it is stated: 'and there must be at least one visibility or modifier keyword." This begs the question, do we need to modify the translator or the document? best regards, René Jansen. _______________________________________________ Ibm-netrexx mailing list [hidden email] |
|
|
René,
IMO implementations should be compliant to language specification. Any deviation should be flagged as a bug to be corrected in a NetRexxC 2.06 version. If there is a risk to break existing (incorrect) programs, then a non-default compiler switch should be added to allow for the prior (wrong behaviour).
Still, in this particular case the specification already allows "no properties instruction at all". Using a properties instruction on its own makes no additional sense. Having more than one way to express something is not "the Rexx way", that would be more like "the PERL way"...
If a new specification with incompatible changes is to be published, then a new implementation version should be built which is compliant to it and ,probably, a compiler switch should be added to allow for processing of code compliant to the former specification .
It goes without saying that doing this would be much more "compliant to the soul of the Rexx way" than adapting the specification to some odd behaviour of the reference implementation. Just my 2 cents :-)
2010/11/21 René Jansen <[hidden email]>
-- Saludos / Regards, David Requena _______________________________________________ Ibm-netrexx mailing list [hidden email] |
|
|
Hi David,
I would be for changing the doc here: 1) it will break existing programs if we change the translator 2) having 'properties' on its own is maybe silly, but at least it shows where the properties start 3) it seems more 'in the spirit' of the design to allow it But this is exactly where we need the language architecture board for - I'll add it as the first agenda item. I wonder what Mike thinks about this. best regards, René. On 21 nov 2010, at 20:16, David Requena wrote: René, _______________________________________________ Ibm-netrexx mailing list [hidden email] |
|
|
In reply to this post by David Requena
+1 on all points.
-Chip- On 11/21/10 19:16 David Requena said: > René, > > IMO implementations should be compliant to language specification. Any > deviation should be flagged as a bug to be corrected in a NetRexxC 2.06 > version. If there is a risk to break existing (incorrect) programs, then > a non-default compiler switch should be added to allow for the prior > (wrong behaviour). > > Still, in this particular case the specification already allows "no > properties instruction at all". Using a properties instruction on its > own makes no additional sense. Having more than one way to express > something is not "the Rexx way", that would be more like "the PERL way"... > > If a new specification with incompatible changes is to be published, > then a new implementation version should be built which is compliant to > it and ,probably, a compiler switch should be added to allow for > processing of code compliant to the former specification . > > It goes without saying that doing this would be much more "compliant to > the soul of the Rexx way" than adapting the specification to some odd > behaviour of the reference implementation. > > Just my 2 cents :-) > > 2010/11/21 René Jansen <[hidden email] <mailto:[hidden email]>> > > Experimentation with Bill Finlason's excellent and very promising > Eclipse plugin for NetRexx yields a question which one is right: the > translator or the documentation. This is because I tend to use a > 'properties' statement on its own when I am in a hurry, and let it > default to inheritable. "Why use a properties statement at all > then?", is a legitimate question, to which I do not know the answer. > > Anyway, a 'properties' followed by a newline causes an error flagged > by the plugin's grammar. Now Bill reminded me of page 111 in nrl2, > where it is stated: 'and there must be at least one /visibility/ or > /modifier/ keyword." > > This begs the question, do we need to modify the translator or the > document? > > best regards, > > René Jansen. > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] <mailto:[hidden email]> > > > > > > -- > Saludos / Regards, > David Requena > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > _______________________________________________ Ibm-netrexx mailing list [hidden email] |
|
|
In this particular case the compiler could generate a warning. That way
programs will still work, but one would be encouraged to clean them up. A bit like the behaviour when using DO for a LOOP. Mike (offline for the next few days). > -----Original Message----- > From: [hidden email] > [mailto:[hidden email]] On Behalf Of Chip Davis > Sent: 22 November 2010 05:25 > To: IBM Netrexx > Subject: Re: [Ibm-netrexx] properties instruction > > +1 on all points. > > -Chip- > > On 11/21/10 19:16 David Requena said: > > René, > > > > IMO implementations should be compliant to language > > specification. Any > > deviation should be flagged as a bug to be corrected in a NetRexxC > > 2.06 version. If there is a risk to break existing (incorrect) > > programs, then a non-default compiler switch should be > > added to allow > > for the prior (wrong behaviour). <snip> _______________________________________________ Ibm-netrexx mailing list [hidden email] |
Re: properties instruction
|
|
+1 for this suggestion and it's implementation ASAP.
Thomas. ================================================ Am 22.11.2010 08:02, schrieb Mike Cowlishaw: > In this particular case the compiler could generate a warning. That way > programs will still work, but one would be encouraged to clean them up. A bit > like the behaviour when using DO for a LOOP. > > Mike (offline for the next few days). > > >> -----Original Message----- >> From: [hidden email] >> [mailto:[hidden email]] On Behalf Of Chip Davis >> Sent: 22 November 2010 05:25 >> To: IBM Netrexx >> Subject: Re: [Ibm-netrexx] properties instruction >> >> +1 on all points. >> >> -Chip- >> >> On 11/21/10 19:16 David Requena said: >>> René, >>> >>> IMO implementations should be compliant to language >>> specification. Any >>> deviation should be flagged as a bug to be corrected in a NetRexxC >>> 2.06 version. If there is a risk to break existing (incorrect) >>> programs, then a non-default compiler switch should be >>> added to allow >>> for the prior (wrong behaviour). > <snip> > > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > > -- Thomas Schneider Projects PP, ReyC, and LOGOS on www.KENAI.com www.thsitc.com _______________________________________________ Ibm-netrexx mailing list [hidden email]
Tom. (ths@db-123.com)
|
|
|
In reply to this post by Mike Cowlishaw
I think that just changing the implementation to issue a warning
would be not advisable.
Because there still would be a mismatch between the language document and the baseline implementation, the implementation is non-conforming. Unless the document is changed, a Properties statement (without keywords) should be an error. It is unfortunate that the baseline implementation accepts non-conforming statements. But just because the implementation did not flag the errors, that does not change the fact that they are errors. I agree with David that the first thing to be done is to make sure that the implementation is changed so that it conforms to the language specification. We don't know if there are other cases like this, but certainly an effort to verify that the implementation conforms totally to the language specification document should be undertaken. (Difficult until the source is released.) I don't agree with David that a permissive option should be added. If the broken statements are to be made legitimate, the language definition document should be changed to make the keywords optional, not by providing a loophole for non-conforming statements in the first reference implementation. This is one of those "pay me now or pay me later" things. Adding a permissive option just perpetuates the acceptance of non-conforming statements, and most likely it would have to be made permanent. I think legitimizing non-conforming statements by an option is not a good idea, now or later. Not treating the broken statement as broken implies that the first implementation defined the language, not the document. Bill Fenlason On 11/22/2010 2:02 AM, Mike Cowlishaw wrote: In this particular case the compiler could generate a warning. That way programs will still work, but one would be encouraged to clean them up. A bit like the behaviour when using DO for a LOOP. Mike (offline for the next few days).-----Original Message----- From: [hidden email] [[hidden email]] On Behalf Of Chip Davis Sent: 22 November 2010 05:25 To: IBM Netrexx Subject: Re: [Ibm-netrexx] properties instruction +1 on all points. -Chip- On 11/21/10 19:16 David Requena said:René, IMO implementations should be compliant to language specification. Any deviation should be flagged as a bug to be corrected in a NetRexxC 2.06 version. If there is a risk to break existing (incorrect) programs, then a non-default compiler switch should be added to allow for the prior (wrong behaviour).<snip> _______________________________________________ Ibm-netrexx mailing list [hidden email] ----- No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1153 / Virus Database: 424/3271 - Release Date: 11/21/10 _______________________________________________ Ibm-netrexx mailing list [hidden email] |
Re: properties instruction
|
|
My *personal Opinion* is as follows: 1.) We should (and *shall*) discuss all those minor issues *at* the upcoming REXXLA 2010 meeeting in *depth 2.) When you, Mike, David, and Kermit, *are **NOT** there*.... ... we won't havce the chance to *discuss this in detail* :-) Thus, as *quicker* **and** *better* you do make your plans to **' come to the REXXLA 2010 meeting** As quicker we can make the proper decisions ....i: Sorry to say: Whithout meeting you all, there, in this upcoming FORUM. ** the whole FORUM** might be use-less :-( :-( :-( Kind regards from dark Vienna, Austria Thomas Schneider. ============================================================ Am 22.11.2010 21:43, schrieb Bill Fenlason: I think that just changing the implementation to issue a warning would be not advisable. _______________________________________________ Ibm-netrexx mailing list [hidden email]
Tom. (ths@db-123.com)
|
|
|
In reply to this post by billfen
Bill,
I wasn't advocating for such a compiler switch but exposing a compromise I *could* agree on for more involved cases than this one. Of course any broken programs because of "single properties" are easily and safely fixable by a simple regex search and replace.
At any rate, this would be a compiler extension, never a language extension. Whether a given programmer is willing to renounce using other fully compliant language processing tools just because he's fond of this particular NetRexxC oddity is his own call. As an example, once upon a time I liked GCC's C array bounds checking.It was cool but I never used it as it'd have tied my code to this particular compiler.
Of course modifying the specification just because a compliant tools uncovers a bug in an implementation (hence forcing modification of any other tools, the former inclusive) is just not right (nor fair!).
Tool developers should be looking at the specification, never investigating the actual behaviour of a given implementation. IMHO it doesn't matter it's the reference one, if it's open or closed source, etc.
Lets discuss if "properties instruction on its own" should be allowed in NetRexx 3 but in the meantime lets fix NetRexxC and NetRexxA to conform to NetRexx 2.05 specification.
2010/11/22 Bill Fenlason <[hidden email]>
-- Saludos / Regards, David Requena _______________________________________________ Ibm-netrexx mailing list [hidden email] |
|
|
In reply to this post by billfen
Nothing keeps such errors from creeping back in as NetRexx develops. Doesn't this argue for a suite of regression tests?
On Mon, Nov 22, 2010 at 3:43 PM, Bill Fenlason <[hidden email]> wrote:
_______________________________________________ Ibm-netrexx mailing list [hidden email] |
|
|
In reply to this post by billfen
2010/11/22 Bill Fenlason <[hidden email]>
Oh, there's another non-conforming case I've mentioned several times here. I'm presenting a more general view here.
I'm very interested in hearing about your (everyone's on the list) views on the issue. Issue: "Variable references" (TRL p.129) in parse templates don't honour NetRexx name lookup rules. In particular NetRexxC does not treat such a reference as a "term" as it should (TRL p.65)
Consecuences: 1 - "Used classes" (TRL p.76) static properties cannot be used as a variable reference in a parse template. Ultimately happens to be a particular case of 2 2 - "Compound terms" (TRL p.42) cannot be used to specify a variable in a parse template.
Test case: class UsedClass private properties public constant -- constant implies static
STATIC_ELEVEN = 11
class SomeClass private
properties public
INSTANCE_ELEVEN = 11 class ParseTest uses UsedClass properties constant testString = "1 cat is surely less louder than 11 cats"
LOCAL_ELEVEN = 11 method main(args=String[]) static
-- ================================
-- simple variable reference is OK -- ================================
parse testString . (LOCAL_ELEVEN) cats say "parse using local property:" cats
-- =======================================
-- variable reference not trated as a term -- =======================================
-- qualified local reference won't compile ("Error: Variable name expected" at "this")
parse testString . (this.LOCAL_ELEVEN) cats instance = SomeClass() say "instance.INSTANCE_ELEVEN in this context:" instance.INSTANCE_ELEVEN -- OK
-- qualified external reference won't compile ("Error: Right parenthesis expected" at the dot)
parse testString . (instance.INSTANCE_ELEVEN) cats -- =====================================
-- 'used' classes variables not resolved -- =====================================
say "'Used' STATIC_ELEVEN in this context:" STATIC_ELEVEN -- OK
-- 'used' classes name lookup not applied ("Error: Variable name expected" at "STATIC_ELEVEN")
parse testString . (STATIC_ELEVEN) cats -- qualified access to statics doesn't work either as per above ("Error: Variable name expected" at "UsedClass")
parse testString . (UsedClass.STATIC_ELEVEN) cats Conclusión: NetRexxC and NetRexxA 2.06 should be fixed so "variable references" are treated as "terms", thus resolved prior calling "netrexx.lang.RexxParse.parse()" method (yes, that is an implementation detail to which the specification should be fully unconcerned)
Addendum: IMHO for an upcoming NetRexx 3 language specification this "variable reference" construct should be replaced by "expression pattern". That would be much more useful while still supporting the current (broken) "variable reference" mechanism.
Saludos / Regards, David Requena _______________________________________________ Ibm-netrexx mailing list [hidden email] |
|
|
Hi All,
As Bill Fenlason correctly points out off-list, NetRexx2.pdf contains the following remark at page 111: "Any variables used in the template are named by non-numeric symbols (that is, they cannot be an array reference or other term); they refer to a variable or property in the current class." This is new to NetRexx2.pdf and would effectively render my stated points moot but raises another more important question: which is the actual NetRexx Language definition? Evidently, from my references to TRL, I've been referring to the language as specified in The NetRexx Language plus The language supplement. That is what is available at IBM's pages.
Here both specs are clearly in disagreement in spite of Mike stating that this NetRexx2.pdf is an integration of the 2 former separated documents not a superseding specification (maybe I got this wrong) Sure my comments are nonsense according to Netrexx2.pdf. Is that the agreed language specification? Are there other points where the 2 documentation sets differ?
2010/11/23 David Requena <[hidden email]>
-- Saludos / Regards, David Requena _______________________________________________ Ibm-netrexx mailing list [hidden email] |
Re: properties instruction
|
|
When writing Rexx2Nrx, years ago, one the *biggest astonishment*
factors have been, that in the PARSE statement stem members can be used in *classic Rexx*, but *not in NetRexx* :-( I did resolve that by temporry variables, and generating the proper assignments in Rexx2Nrx :-) Thomas. ========================================================== Am 23.11.2010 17:50, schrieb David Requena: Hi All, _______________________________________________ Ibm-netrexx mailing list [hidden email]
Tom. (ths@db-123.com)
|
|
|
In reply to this post by David Requena
I sometimes use the RexxLA web site as a resource. As a non-member
I have little right to be critical, but I am rather surprised that
the site is so badly out of date with regard to NetRexx and MFC.
Perhaps somewhere on the public RexxLA pages there is a link to the NetRexx 2 document (or even MFC's current home page), but I could not find it. The only NetRexx link points to the IBM site, and that only references the original document and supplement. On 11/23/2010 11:50 AM, David Requena wrote: Hi All, _______________________________________________ Ibm-netrexx mailing list [hidden email] |
|
|
Hi All,
In my view agreeing in a single official language definition is of the outmost importance. I think this should be point one of the NetRexx board once assembled. Having 2 separate specs (supposedly differing just in formatting) which actually happen to differ in the details is just not serious, nor workable. If netrexx2.pdf is to be designated the official specification, I'll need to give it deep study before engaging in further detailed discussion of any language aspects. I expect not to be alone on this :-( Not that I really advocate either option. This just needs to be settled ASAP. - Saludos / Kind regards, David Requena -----Original Message----- From: Bill Fenlason <[hidden email]> Sender: [hidden email] Date: Tue, 23 Nov 2010 12:56:05 To: IBM Netrexx<[hidden email]> Reply-To: IBM Netrexx <[hidden email]> Subject: Re: [Ibm-netrexx] properties instruction _______________________________________________ Ibm-netrexx mailing list [hidden email] _______________________________________________ Ibm-netrexx mailing list [hidden email] |
Re: properties instruction
|
|
+ oo (plus eternity) for Davids suggestion.
Let us make NetRexx2.pdf the *official language spec*. I also would like to *underline* the importance to have *only one language spec* :-) Thomas Schneider. ======================================================== Am 23.11.2010 20:13, schrieb David Requena: > Hi All, > > In my view agreeing in a single official language definition is of the outmost importance. > > I think this should be point one of the NetRexx board once assembled. Having 2 separate specs (supposedly differing just in formatting) which actually happen to differ in the details is just not serious, nor workable. > > If netrexx2.pdf is to be designated the official specification, I'll need to give it deep study before engaging in further detailed discussion of any language aspects. I expect not to be alone on this :-( > > Not that I really advocate either option. This just needs to be settled ASAP. > > > - > Saludos / Kind regards, > David Requena > > -----Original Message----- > From: Bill Fenlason<[hidden email]> > Sender: [hidden email] > Date: Tue, 23 Nov 2010 12:56:05 > To: IBM Netrexx<[hidden email]> > Reply-To: IBM Netrexx<[hidden email]> > Subject: Re: [Ibm-netrexx] properties instruction > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > > > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > > -- Thomas Schneider Projects PP, ReyC, and LOGOS on www.KENAI.com www.thsitc.com _______________________________________________ Ibm-netrexx mailing list [hidden email]
Tom. (ths@db-123.com)
|
|
|
What and where are the 'original' specs. This could take on religious overtones: Who has the Original Word.
bobh _______________________________________________ Ibm-netrexx mailing list [hidden email] |
|
|
In reply to this post by David Requena
Hi all, I've been away for a few days, so anm skimming through
the many posts. I think most items have been resolved, but will
comment where I think they have not been. Nudge me for more if
necessary.
Here's one:
_______________________________________________ Ibm-netrexx mailing list [hidden email] |
|
|
2010/11/24 Mike Cowlishaw <[hidden email]>
oh,of course you're right. It seems I paid much more attention to the long 'parsing' article the actual 'parse' intruction description page. That is of course my fault. So, ok. I'll turn my original bug report into a request for enhancement when the time comes ;-)
Yes, agreed. I was intending to use TNRL but somehow managed to get it wrong. Finger memory did the rest. _______________________________________________ Ibm-netrexx mailing list [hidden email] |
«
Return to ibm-netrexx
|
1 view|%1 views
| Free forum by Nabble | Edit this page |