Sorry , maybe a funtion was a bad example although all of the same
principles apply to subroutines as well, see below. What really prompted
me to reply was the position that locally scoped variables were
complex, difficult and hard to understand. I applaud you for exploring
the world of computer programming beyond the mv world - but judging the
concepts of these languages based on the backwater 1970's thinking
behind standard mv-basic is really the wrong way to go.
val=0
first_sub = 1
second_sub = 2
gosub doit
first_sub = 3
second_sub = 4
gosub doit
first_sub = 5
second_sub = 6
gosub doit
stop
* have to be careful here not to stomp an existing variables
* recursion - forget it
doit:
...
return
or
val=0
gosub doit( 1 , 2 )
gosub doit( 3 , 4 )
gosub doit( 5 , 6 )
stop
* no need here to worry about stomping on existing variables
* can re/use any var names as they are locally scoped
* recursion - no problem
subroutine doit( first , second )
...
return
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bill Haskett
Sent: December 18, 2006 5:56 PM
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] [BB] Internal functions and scope in Basic
Gerry:
Please forgive my general obtuse view. It seems to me your argument,
and
example, is that functions are preferable to subroutines in a number of
instances. I don't disagree with this argument.
You pointed out the most obvious reason for using local subroutines or
functions in a PICK environment: runtime resource problems when calling
external subroutines. This problem has existed for as long as I can
remember in PICK and has lead to INCLUDEs and a general non-modularation
of
PICK style code.
It used to be that an array, read and processed from one end to another,
always started at the beginning for each reference. U2 resolved this be
keeping a pointer to the last reference, so that reasonably sized array
manipulations wouldn't slow to a crawl as the size of the array
increased;
or require tricks like creating select lists to use READNEXT or use
REMOVE
to process the array.
I guess my point is why can't IBM do something about this long-standing
runtime problem, rather than creating a new structure that improves the
performance of the "work-around" we all use?
Bill
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of gerry-u2ug
Sent: Monday, December 18, 2006 1:21 PM
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] [BB] Internal functions and scope in Basic
Locally scoped variables complex , difficult , hard to understand ?
Wow. Welcome to the 1980's.
Even 'simple' scripting languages have employed this fundamental
programming concept for quite some time.
Honestly, anyone needing an answer to the 'why' ... never mind ;-)
The lack of locally scoped variables can make things much messier than
they need to be and also much harder to maintain - especially true for
large programs.
Resorting to single-use external routines can greatly simplify some
tasks ( recursion for instance ) but can also have a horrendous effect
on performance. Internal routines with locally scoped variables should
provide all the benefits without all the overhead.
Internal routines would also eliminate one of the elements that
contribute to the perception by some of U2 as 'kiddie systems'
Which do you find simpler and easier to code / maintain :
first_sub = 1
second_sub = 2
gosub doit
val1 = rtn_sub
first_sub = 3
second_sub = 4
gosub doit
val1 = rtn_sub
first_sub = 5
second_sub = 6
gosub doit
val1 = rtn_sub
val = val1 + val2 + val3
stop
* have to be careful here not to stomp an existing variables
* recursion - forget it
doit:
...
rtn_sub = ...
return
or
val = doit( 1 , 2 ) + doit( 3 , 4 ) + doit( 5 , 6 )
stop
* no need here to worry about stomping on existing variables
* can re/use any var names as they are locally scoped
* recursion - no problem
function doit( first , second )
...
return (...)
-------
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
-------
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
