RE: [UV] Recursive GOSUB
Yes. Brian Leach > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Marco Manyevere > Sent: 01 March 2004 10:08 > To: [EMAIL PROTECTED] > Subject: [UV] Recursive GOSUB > > Hi All, > > Can a UV GOSUB directly or indirectly refer to itself? > Something like so: > > LABEL: > >IF (SOME.CONDITION) THEN GOSUB LABEL > >RETURN > > > Regards, Marco > > > - > Yahoo! Messenger - Communicate instantly..."Ping" your > friends today! Download Messenger Now > -- > u2-users mailing list > [EMAIL PROTECTED] > http://www.oliver.com/mailman/listinfo/u2-users > > __ > __ > This email was checked by MessageLabs SkyScan before entering > Microgen. This email was checked on leaving Microgen for viruses, similar malicious code and inappropriate content by MessageLabs SkyScan. DISCLAIMER This email and any attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information. In the event of any technical difficulty with this email, please contact the sender or [EMAIL PROTECTED] Microgen Information Management Solutions http://www.microgen.co.uk -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
RE: [UV] Recursive GOSUB
Only if the Code Auditor is asleep :-) -Original Message- From: Marco Manyevere [mailto:[EMAIL PROTECTED] Sent: 01 March 2004 10:08 To: [EMAIL PROTECTED] Subject: [UV] Recursive GOSUB Hi All, Can a UV GOSUB directly or indirectly refer to itself? Something like so: LABEL: IF (SOME.CONDITION) THEN GOSUB LABEL RETURN Regards, Marco - Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ Confidentiality Notice: This e-mail and any attachments are intended solely for the addressee and may contain confidential or privileged information. If you are not the named addressee, or the person responsible for delivering the message to the named addressee, please notify the sender as soon as possible and delete the material from your computer. This message will be protected by copyright. If it has come to you in error, you must not take any action based on its contents nor must you copy or show the message to any person other than the intended recipient. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
Re: [UV] Recursive GOSUB
Yes, you can do GOSUB's recursively. Most often it happens by accident and you hit the limit (256?) of GOSUB depth. The only problem is that internal subroutines do not have local variables so the second call is using the same variables as its parent. If this is a problem, using dynamic arrays to stack the necessary items is quite neat. Be sure to document thoroughly what you are doing in the code or you will open up a whole new area for disasters when someone comes to modify the routine in the future. Martin Phillips Ladybridge Systems 17b Coldstream Lane, Hardingstone, Northampton NN4 6DB +44-(0)1604-709200 - Original Message - From: "Marco Manyevere" <[EMAIL PROTECTED]> > Can a UV GOSUB directly or indirectly refer to itself? Something like so: > > LABEL: > >IF (SOME.CONDITION) THEN GOSUB LABEL > >RETURN -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
RE: [UV] Recursive GOSUB
> The only problem is that internal subroutines do not have local > variables so > the second call is using the same variables as its parent. If this is a > problem, using dynamic arrays to stack the necessary items is quite neat. > At the risk of sounding like an ad, there's an article at http://www.precisonline.com/inner.html discussing the concept of "inner recursion", that is, recursing inside of a single program. --Kevin [EMAIL PROTECTED] http://www.PrecisOnline.com -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
RE: [UV] Recursive GOSUB
This is an interesting topic as this concept within BASIC was actually developed and tested with great success here, though unfortunately never implemented for field release. I don't quite recall now how the implementation was done, but I believe there was a new statement used to indicate that an internal subroutine was either global or local and that would determine how variables were treated. I don't believe it was that difficult to implement either... Anyways, it sure would be a nice feature in the real world! At 09:49 AM 03/01/2004, you wrote: > The only problem is that internal subroutines do not have local > variables so > the second call is using the same variables as its parent. If this is a > problem, using dynamic arrays to stack the necessary items is quite neat. > At the risk of sounding like an ad, there's an article at http://www.precisonline.com/inner.html discussing the concept of "inner recursion", that is, recursing inside of a single program. --Kevin [EMAIL PROTECTED] http://www.PrecisOnline.com -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
RE: [UV] Recursive GOSUB
All you really need is an open-ended while loop. No recursion is necessary, not even internal recursion with gosubs. For a "tree" type example: list = root.item list.cntr = 1 while (list<1,list.cntr> # '') do children = list.children child.ins.cntr = list.cntr for child.cntr = 1 to num.children child = children<1,child.cntr> if (child not already in list) then ;* in case tree is really a graph with circuits child.ins.cntr = child.ins.cntr + 1 list = ins(list,1,child.ins.cntr,child) end next child.cntr list.cntr = list.cntr + 1 repeat From: [EMAIL PROTECTED] on behalf of Kevin King Sent: Mon 3/1/2004 9:49 AM To: U2 Users Discussion List Subject: RE: [UV] Recursive GOSUB > The only problem is that internal subroutines do not have local > variables so > the second call is using the same variables as its parent. If this is a > problem, using dynamic arrays to stack the necessary items is quite neat. > At the risk of sounding like an ad, there's an article at http://www.precisonline.com/inner.html discussing the concept of "inner recursion", that is, recursing inside of a single program. --Kevin [EMAIL PROTECTED] http://www.PrecisOnline.com -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users Our company accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. 11/29/2003 ACE Software, LLC -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
RE: [UV] Recursive GOSUB
Hey, since I did it, let me help :-) Basically, as you mentioned, it allowed a new statement to define 'scoped' regions that would always have local variables. So, for instance, you could do: PROGRAM A Var1 = "Test" PRINT "PreVersion of Var1 = ":Var1 GOSUB localSub1 PRINT "PostVersion of Var1 = ":Var1 STOP localSub1: $LOCALSTART <--- New construct Var1 = "NewTest" PRINT "NewValue of Var1 = ":Var1 $LOCALEND Would print PreVersion of Var1 = Test NewValue of Var1 = NewTest PostVersion of Var1 = Test In fact, the 'scoping' allowed you to provide this boundary mechanism at any point, not just around subroutines, so you could have A=9 PRINT A $LOCALSTART A = 99 PRINT A $LOCALSTART A=999 PRINT A $LOCALEND PRINT A $LOCALEND PRINT A would print : 9 99 999 99 9 Additionally, there was a mechanism to define 'global' variables that would span LOCAL blocks, so that the newly defined global variable would be one that could be modified in the LOCAL scopes, and have those changes reflected out, as well as all for values to be started in. All in all, a very interesting and potentially powerful concept... Worked great too... Alas, it never went in... And yeah, it took me all of about 2 days to put in... Dave At 09:58 AM 3/1/2004 -0500, you wrote: This is an interesting topic as this concept within BASIC was actually developed and tested with great success here, though unfortunately never implemented for field release. I don't quite recall now how the implementation was done, but I believe there was a new statement used to indicate that an internal subroutine was either global or local and that would determine how variables were treated. I don't believe it was that difficult to implement either... Anyways, it sure would be a nice feature in the real world! At 09:49 AM 03/01/2004, you wrote: > The only problem is that internal subroutines do not have local > variables so > the second call is using the same variables as its parent. If this is a > problem, using dynamic arrays to stack the necessary items is quite neat. > At the risk of sounding like an ad, there's an article at http://www.precisonline.com/inner.html discussing the concept of "inner recursion", that is, recursing inside of a single program. --Kevin [EMAIL PROTECTED] http://www.PrecisOnline.com -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users David T. Meeks || "All my life I'm taken by surprise Architect, Technology Office || I'm someone's waste of time Ascential Software || Now I walk a balanced line [EMAIL PROTECTED] || and step into tomorrow" - IQ -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
Re: [UV] Recursive GOSUB
> Can a UV GOSUB directly or indirectly refer to itself? YES! This technique has been employed by me ever since I started in Pick in 1983 as my first assignment was to write reports for complicated Bills of Materials for a manufacturer of Radio and TV's. There was another reference to an article on internal recursion which stated it very well. I have included the link here again for those that may have missed it. > http://www.precisonline.com/inner.html < However I did want to remind the listener that Retrieve (and indeed Pick all those years ago) also supports this concept. Refer to the "WITHIN" keyword - and have fun! Cheers Trevor Ockenden OSP --- Outgoing mail is certified Virus Free by AVG 6.0. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.601 / Virus Database: 382 - Release Date: 1/03/2004 -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
Re: [UV] Recursive GOSUB
Dave, >$LOCALSTART <--- New construct >Var1 = "NewTest" >PRINT "NewValue of Var1 = ":Var1 >$LOCALEND when you implemented this, did it add new opcodes or change the object format, or were the objects still backwards compatible with previous versions and the $LOCALxxx directives just affecting the compiler? (or between the lines: if I contact IBM and suggest they retrive this code and add it to UV, do you think I will still be able to copy object from UV10.x to UV9.x) thanks, Craig -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
RE: [UV] Recursive GOSUB
|Dave, | |>$LOCALSTART <--- New construct |>Var1 = "NewTest" |>PRINT "NewValue of Var1 = ":Var1 |>$LOCALEND | |when you implemented this, did it add new opcodes or change the object |format, |or were the objects still backwards compatible with previous versions and |the $LOCALxxx directives just affecting the compiler? | |(or between the lines: if I contact IBM and suggest they retrive this code |and add it to UV, do you think I will still be able to copy object from |UV10.x to UV9.x) | |thanks, No, this was not a new opcode, but rather, a construct within the lexical analyzer. So yes, this would be perfectly portable, at least the object code would be... at least insofar as any other object code would be. Obviously, the source code would fail to compile... Essentially, during a pre-pass phase of the compilation, the lexer will examine the tokens to determine if the referenced value is a variable or not. It will then determine whether the variable has been seen or not. If so, it returns that entry in the vartab slot (where you see in the 'VLIST ... R' listing the slot values. The change basically established scope levels inside the analyzer to disambiguate between variables that were local/global scope. Thus, in the construct: A=1 $LOCALSTART A=2 $LOCALEND The lexer would see the 'A', determine it was a LVALUE (variable), and assign it to slot one. The parser would then construct the opcode using the "move" opcode, using slot 1. The second statement, however, would be within a local scope, so the lexer would mark the boundary in the vartab table, and again, upon determining that 'A' was an LVALUE(variable), it would look up the value, find that it wasn't in the vartab (at least within the local scope range), and assign it a new slot. Effectively, this treats it as if you named it 'A' and 'Local1A', as the actual run-time component doesn't care. Now, there were also mechanisms to mark certain variables as being global scope as well, that I haven't discussed. Now, as to whether IBM could get the code and put it in... the answer is most likely NO. IBM and Ascential are separate organizations, and our code streams are separate and effectively protected. Now, if Susie/Helen were to give me a call, I could probably tell them exactly how to do this.. Hey... didn't this post already do that :-) Dave David T. Meeks || "All my life I'm taken by surprise Architect, Technology Office || I'm someone's waste of time Ascential Software || Now I walk a balanced line [EMAIL PROTECTED] || and step into tomorrow" - IQ -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
Re: [UV] Recursive GOSUB
>Now, as to whether IBM could get the code and put it in... the answer is >most likely NO. IBM and Ascential are separate organizations, and our >code streams are separate and effectively protected. Ah, I thought you were suggesting this was work done at Ardent/Informix but never released. thanks for the explanation Dave, Craig -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
