Re: [UV] Recursive GOSUB

2004-03-02 Thread Craig Bennett
>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. than

RE: [UV] Recursive GOSUB

2004-03-02 Thread David T. Meeks
|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 direct

Re: [UV] Recursive GOSUB

2004-03-01 Thread Craig Bennett
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

Re: [UV] Recursive GOSUB

2004-03-01 Thread Trevor Ockenden
> 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

RE: [UV] Recursive GOSUB

2004-03-01 Thread David T. Meeks
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

RE: [UV] Recursive GOSUB

2004-03-01 Thread Dave Davis
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

RE: [UV] Recursive GOSUB

2004-03-01 Thread Glenn Herbert
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

RE: [UV] Recursive GOSUB

2004-03-01 Thread Kevin King
> 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:/

Re: [UV] Recursive GOSUB

2004-03-01 Thread Martin Phillips
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 t

RE: [UV] Recursive GOSUB

2004-03-01 Thread Bob Witney
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:

RE: [UV] Recursive GOSUB

2004-03-01 Thread Brian Leach
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? > Somet