Jbase programming query

[Dhaya]

Hi

I am using jbase 4.1 release with T24. I have a query regarding the
usage of 'recursive return" statement
in Jbase programming language. I understood we can recursive return
to come out of subroutine to calling program. I have a requirement
where when the recursive return is executed, program control should
not come out
the subroutine used. It is that is there any way to code such as

PROGRAM.ABORT:

RETURN TO (PROGRAM.ABORT - 1)

Because, i want this recursivee return to be executed 1 level down.
Can i use (PROGRAM.ABORT - 1) in jbasic
or Is there any alternate way to use.

Thanks

[Daniel Klein]

You haven't really given enough detail to provide a specific answer so here's a generic one...

Let's say you want to get the power of 2 to some number N and you want to do this recursively. Yes, I know that there is a PWR() function but this is just for illustration.

First we need a program to set things up:

 

PROGRAM CALL.RECUR

CRT 'Enter a number >= 1':

INPUT N

IF NUM(N) ELSE STOP

IF N < 1 THEN STOP

RESULT = 1

CALL RECUR(N, RESULT)

CRT RESULT

 

Now let's recursively CALL the subroutine N times:

 

SUBROUTINE RECUR(N, RESULT)

* Recursive power of 2

IF N THEN

  RESULT *= 2

  N -= 1

  CALL RECUR(N, RESULT)

END

RETURN

You'll notice that there is a terminating condition that allows the 'stack' to unwind. This is very important otherwise you will end up aborting with a stack overflow error.

Here's another example that uses COMMON instead of subroutine arguments to keep track of things. Let's say we want to traverse a tree in 'postorder' (1. traverse the left subtree, 2. traverse the right subtree, 3. visit the root). A simple graphic example would be (you need a fixed size font to see this accurately):

            1

           / \

          2   3

         / \ / \

         4 5 6 7

such that the nodes would be output in the following order:

    4,5,2,6,7,3,1

The data structure for this would be:

    ID: Node ID

    <1> left link ] right link

where ']' is a VM ( 0xFD ).

Although this is a binary tree, the algorithm works for an m-way tree with any number of subtrees, ie

    ID: Node ID

    <1> link1 ] link2 ] link3 ] ... ] linkX

and is also not restricted to 'balanced' trees where all leaves must be a the same level.

SUBROUTINE VISIT (ROOT)

COMMON TREE, LEVEL

READ LINKS FROM TREE, ROOT THEN

    LINK.CNT = DCOUNT(LINKS,@VM)

    LEVEL += 1

    FOR VAL = 1 TO LINK.CNT

        CALL VISIT(LINKS<1,VAL>)

    NEXT VAL

    LEVEL -= 1

    CRT "Root = ":ROOT:" at level ":LEVEL

END

RETURN

We need a program to start things off:

COMMON TREE, LEVEL

OPEN "TREE" TO TREE ELSE STOP

LEVEL = 0

ID = 1; * Set the root node

CALL VISIT (ID)

This would produce the following output:

 

Root = 4 at level 2

Root = 5 at level 2

Root = 2 at level 1

Root = 6 at level 2

Root = 7 at level 2

Root = 3 at level 1

Root = 1 at level 0

To change this to do a 'preorder' traversal, simply move the 'CRT' line just before the 'LEVEL += 1' line. The output produced would then be:

Root = 1 at level 0

Root = 2 at level 1

Root = 4 at level 2

Root = 5 at level 2

Root = 3 at level 1

Root = 6 at level 2

Root = 7 at level 2

'Inorder' traversal is a bit more complex and I won't go into it here.

Be aware that jBASE has a 'stack' limit as to the number of levels you can recursively call and I believe the limit is platform dependent.

Performance considerations aside, recursion is generally good for when you don't know how many levels are involved.

Dan

"The work will teach you how to do it." -- Estonian Proverb

[Jim Idle]

Never, ever, ever, ever, ever, ever, ever, ever,ever, ever, ever,
ever,ever,ever, use RETURN TO. That's ever, ever, ever, ever, ever,
ever, ever, ever, ever, ever, ever, ever, ever, ever, ever, ever, ever,
ever, ever, ever, ever, ever, ever, ever, ever ad infinitum.

For a start you will never debug it. Wanting to do this is a sign that
your design is very wrong.

jBC is a compiled language, therefore the line numbers have no meaning
except in the debugger. There are some compiled languages that annotate
lines but they are compiling broken languages.

The reason that you are wanting to do this is either that you have used
GOTO elsewhere in this program, or that you have called nested
subroutines, discovered an error and now want to back out of all the
GOSUBs until you can return from the subroutine. Either way, it means
that you need to redesign your subroutine. Each GOSUB should check an
error return and back out accordingly. This type of thing is why more
modern languages have exceptions that can cascade back up the chain and
be caught at an appropriate point. However jBC does not have this
functionality so you must program accordingly.

Now, personally, I think that the language should have had separate
notation for subroutine vs gosub return, but it doesn't, so you are
stuck with it. Review your design here - when you have to ask how to do
something like this, it means the program is broken.

Jim

[Richard Kann]

You said:

Never, ever, ever, ever, ever, ever, ever, ever,ever, ever, ever, 
ever,ever,ever, use RETURN TO. That's ever, ever, ever, ever, ever, 
ever, ever, ever, ever, ever, ever, ever, ever, ever, ever, ever, ever, 
ever, ever, ever, ever, ever, ever, ever, ever ad infinitum.

But how do you REALLY feel about it Jim?

Richard Kann
Comp-Ware Systems, Inc.

[Simon Verona]

I think it's a case of "you're fired " if you use return to !!!

I can only agree having had to historically debut code with lots of
return to's in!

Simon

---------------------------------
Simon Verona
Director
Dealer Management Services Ltd

Sent from my iPhone

[Mark Hogden]

Oh so you're the one.

Did you 'debut' ALTER in COBOL as well ?

[Simon Verona]

Oops. I blame fat fingers and an iPhone !!!

---------------------------------
Simon Verona
Director
Dealer Management Services Ltd

Sent from my iPhone

[Richard Kann]

I've seen worse though I agree on the return to's. The other issue is goto statements that jump all over the world rather then using if then's or other more smooth routines. Maybe it's my age, but back in the old days it caused massive frame faulting making the disc run constant. These days I guess it is not as important though still a pain to debug.

[Simon Verona]

I think that good programming techniques don’t change.. nice, clear, concise code (with comments) is massively easier to develop, debug and has less bugs inserted with ongoing maintenance and updates...

 

My nightmare is code like (I was looking at code similar to this earlier in the week)...

 

                IF X=2&Y=1&Z=3 THEN

                     A=A+1

                    J<X,Y>=R<Z>

                   GO 100

             END ELSE

                  GO 200

             END

     

This is just a snippet of the kind of code I was debugging – about 1000 lines of code in the same vein, without a single comment! 

 

Such fun!

 

Simon

 

 

From: jB...@googlegroups.com [mailto:jB...@googlegroups.com] On Behalf Of Richard Kann
Sent: 03 March 2009 23:49
To: jB...@googlegroups.com
Subject: Re: Jbase programming query

 

I've seen worse though I agree on the return to's. The other issue is goto statements that jump all over the world rather then using if then's or other more smooth routines. Maybe it's my age, but back in the old days it caused massive frame faulting making the disc run constant. These days I guess it is not as important though still a pain to debug.

Simon Verona wrote:

[Richard Kann]

The old I learned basic programming in school. Who needs those new fangled large variable names or comments. Try this for size:


L=5
GOSUB 9000
A5=VAR
L=30
GOSUB 9000
A7=VAR
.
.
.  <some 300 lines later>
9000 INPUT VAR
IF LEN(VAR)>L THEN GO 9000
RETURN

This was a 15000 line program, the variables were all defined way up at the top (at least 1/2 were, the new fields were left out). There were actually 8 or 9 different subroutine areas for common inputs, prints, etc. I got whiplash trying to read the code.


Richard Kann

Simon Verona wrote:

--~--~---------~--~----~------------~-------~--~----~
Please read the posting guidelines at: http://groups.google.com/group/jBASE/web/Posting%20Guidelines

IMPORTANT: Type T24: at the start of the subject line for questions specific to Globus/T24

To post, send email to jB...@googlegroups.com
To unsubscribe, send email to jBASE-un...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/jBASE?hl=en
-~----------~----~----~----~------~----~------~--~---

[Bruce Willmore]

My personal favorite was a line of code that a Contractor did at a
site I was working at about 15 years ago.

XXX = X + XX

> > This is just a snippet of the kind of code I was debugging -- about

> > 1000 lines of code in the same vein, without a single comment!
>
> > Such fun!
>
> > Simon
>

> > *From:* jB...@googlegroups.com [mailto:jB...@googlegroups.com] *On
> > Behalf Of *Richard Kann
> > *Sent:* 03 March 2009 23:49
> > *To:* jB...@googlegroups.com
> > *Subject:* Re: Jbase programming query

>
> > I've seen worse though I agree on the return to's. The other issue is
> > goto statements that jump all over the world rather then using if
> > then's or other more smooth routines. Maybe it's my age, but back in
> > the old days it caused massive frame faulting making the disc run
> > constant. These days I guess it is not as important though still a
> > pain to debug.
>
> > Simon Verona wrote:
>
> > I think it's a case of "you're fired " if you use return to !!!
>
> > I can only agree having had to historically debut code with lots of  
> > return to's in!
>
> > Simon
>
> > ---------------------------------
> > Simon Verona
> > Director
> > Dealer Management Services Ltd
>
> > Sent from my iPhone
>

> >         Jim- Hide quoted text -
>
> - Show quoted text -

[Simon Verona]

You reckon he meant:

XXX=X:XX

???

Simon :)

-----Original Message-----
From: jB...@googlegroups.com [mailto:jB...@googlegroups.com] On Behalf Of
Bruce Willmore
Sent: 04 March 2009 14:39
To: jBASE
Subject: Re: Jbase programming query

[Bruce Willmore]

Hard to say. I think he still lived in a 32KB world. Even did math
with Proc...

>  Simon Verona.vcf
> 7KViewDownload- Hide quoted text -

[Jim Idle]

Bruce Willmore wrote:
> Hard to say. I think he still lived in a 32KB world. Even did math
> with Proc...
>
>
>

I believe you meant to say he calculated arithmetic expressions with
PROC ;-)

Jim

[concern shoko]

At times the best way to debug is to write your own program. Honestly the average time we spend perusing the endless uncommented lines is more than the time we need to write the whole program from scratch....

 

Food for thought....

C. Shoko
Temenos GLOBUS Developer
|Nedbank Africa|South Africa|

[Simon Verona]

Agreed about the long term benefits of rewriting!

Also whilst we're at it - fire any programmer that uses goto, return to, undescriptive variable names or seems incapable of writing comments. Though I did work with a programmer who claimed comments were unnecessary because the code was"self-documenting"!! Strangely enough he also was a big "goto" user....

Simon

---------------------------------

Simon Verona

Director

Dealer Management Services Ltd

Sent from my iPhone

Simon Verona wrote:

<mime-attachment.jpg>

[Richard Kann]

When does that self documentation come out. I have been waiting for 20 years for a copy. :-)

Also add programmers that use long variable names. I had one joker who came from the A, B, C world of variables and was so infatuated with Multi-value that he started using variable names such as QUANTITYONHANDFORTHESTORE or LASTDATEITEMWASCHANGED.

The re-writing is a good idea. I have done that on some code written by one of my former assistant programmers. But it can be cost prohibitive for clients that we are brought into after the fact and have 50k lines of code for an order entry screen that is fairly complex. It is hard to explain to them why it will cost them a few thousand dollars to re-write the code before I can add one little change to a screen. I speak from experience as I had a client like that. I had to pass on doing any changes for him.

[Charlie Noah]

Richard,

I, too, have been waiting, both for the documentation and for some common sense. Too short = bad, too long = bad, just right = goooood!
I think I knew that programmer. Just couldn't say STORE.ONHAND.QTY or LAST.CHANGE.DATE. Some might say that even these are too long.

Chuckling...
Charlie Noah
Inland Truck Parts

[Mike Preece]

On Mar 4, 6:10 pm, Simon Verona <si...@dmservices.co.uk> wrote:
> Agreed about the long term benefits of rewriting!
>
> Also whilst we're at it - fire any programmer that uses goto, return  
> to, undescriptive variable names or seems incapable of writing  
> comments. Though I did work with a programmer who claimed comments  
> were unnecessary because the code was"self-documenting"!! Strangely  
> enough he also was a big "goto" user....
>
> Simon
>

Perhaps controversially, I believe that comments are often a result of
somewhat shabby work. We ought to think twice. Look at the code you've
written and see if there are changes you could make to it that would
make it self explanatory. That little bit of extra effort is, in my
opinion, better than taking the easy way out by throwing in a comment
or two. One argument in favour of this approach is that comments can
end up misleading or extraneous after a code change. It'd be easy for
a programmer to get in and fix or change something, get the code
working as it should, and overlook that the comment should also have
been changed.

And - to add some extra heat to this discussion - GO can sometimes
(although very rarely) have its place. I've seen code that has a flag
set where a GO could have been employed, with multiple subsequent
tests on that flag scattered through the code. In this particular
example, use of a GO would have removed the need for the flag and
simplified the code. OK - the alternative would be to rewrite the
code, but that can be (and usually is) nowhere near cost-effective.

Mike.

[Simon Verona]

Of course, GOTO can be used in a logical and non-problematic way.. The
problem is to define when this is.. I prefer to simply try to avoid the
use of GOTO - there are rarely situations where it's needed!

As for comments... it's one of those things, over-commenting *can* be as bad
as not commenting at all, but I would prefer to have detailed comments than
none at all....

Personally, I try to put a comment block at the top of each program which
describes the use of the routine, how it is called and what it exits with
(most of my programs are written as subroutines). A one-line comment
precedes most subroutines within a program (though the subroutine name is
also descriptive - and certainly not numeric!!!). The odd comment may also
be thrown in if explanation is needed on anything else....

The underlying problem with multi-value programmers, is that they are often
"business" people who learnt to program, rather than programmers who apply
themselves to business.... This is what makes a lot of Multi-value
applications very good - because they are written directly by people who
understand the industry they are programming for... However, for the same
reason, these same people often lack good programming techniques and
application of standards.

Simon

-----Original Message-----
From: jB...@googlegroups.com [mailto:jB...@googlegroups.com] On Behalf Of
Mike Preece
Sent: 04 March 2009 20:43
To: jBASE
Subject: Re: Jbase programming query

[Jim Idle]

Mike Preece wrote:

On Mar 4, 6:10 pm, Simon Verona <si...@dmservices.co.uk> wrote:
  

Agreed about the long term benefits of rewriting!

Also whilst we're at it - fire any programmer that uses goto, return  
to, undescriptive variable names or seems incapable of writing  
comments. Though I did work with a programmer who claimed comments  
were unnecessary because the code was"self-documenting"!! Strangely  
enough he also was a big "goto" user....

Simon

    

Perhaps controversially,

You mean incorrectly.

 I believe that comments are often a result of
somewhat shabby work. 

This could not be more incorrect. The only way you could contrive to make this correct is if the variable were all called A1 A2 A3 etc and they have to be explained. Variables should be:

recordCounter
customerFile

and so on. Comments are rarely about explaining what the code does. I know what COUNT() does and I can even infer G += (A++)+(-l--) does. Comments are about WHY it does it, and no amount of jiggering about with the code explains things like why are particular algorithm was chosen and so on. We would NEVER have to think twice about these things. And anyway, it's only BASIC, it isn't rocket science (expcet for the blokes at JPL that use jBASE that is).

We ought to think twice. Look at the code you've
written and see if there are changes you could make to it that would
make it self explanatory. 

I was going to give lots of examples and so on but I don't think there is any point. I think that you must not have ever seen properly documented code. The comments rarely explain the lines of code that are going to run. Comments say things like:

* Do not be tempted to change this algorithm basing it at 0 as then XYZ is
* required....

* The front desk bell captain must be pinged before the bell as the
* front stufle pump will explode if this happens out of order more than
* 6 times - doing this here before starting the grunk engine guarantees order
*

* We must use a topological sort here as a straight qsort does not account
* for interdependencies and we must detect dependency cycles here
*

* Use dynamic arrays here because....

That little bit of extra effort is, in my
opinion, better than taking the easy way out by throwing in a comment
or two. 

I am sorry but this is utter rubbish. How is adding comments taking an easy way out - I think that perhaps you experience of other programmers can have been only of relatively mediocre ones. Can I guess that a lot of your code does not have comments in then, and you have self justified this by saying "Ah, now I have formatted it a bit, it is obvious"? This isn't how it works at all. Comments remind you of the thought process you went through 3 years ago to type in the program. If I need comments for something I wrote 3 years ago, then how can I expect someone who has never seen the code to get the gestalt?

Also, do not forget that sometimes code that is harder to read might be necessary because it is 10X faster and so on.

One argument in favour of this approach is that comments can
end up misleading or extraneous after a code change. 

It is part of your job as a programmer to look after the code. If you don't update the comments, then you are not doing your job. The number of times I have heard this crap from programmers is unreal. It is like your mechanic saying "I didn't put in any oil in your car because it will be out of date in 6,000 miles anyway". Just because there are comments does not mean you don't read the code.

It'd be easy for
a programmer to get in and fix or change something, get the code
working as it should, and overlook that the comment should also have
been changed.
  

Then he isn't really any good. Good programmers are not hacks who do things that are 'clever' - programming is a profession.

And - to add some extra heat to this discussion - GO can sometimes
(although very rarely) have its place. 

Exit to error condition that does not return. That's it.

Jim

[Tony G]

From: Jim Idle

> Comments are about WHY it does it, and no amount of
> jiggering about with the code explains things like why
> are particular algorithm was chosen and so on.

That's exactly what I was thinking - comments are for Why, not
How. The How might be awful but it's even worse (and a completely
separate issue) when we can't read the How and don't understand
the Why either.

I've been in both situations described in this thread:
- Had a hard time justifying to the client why code needed to be
re-written for a seemingly minor change. (In the end, had to eat
the time put in by one of my contractors just to get the code to
a point where we could do constructive work for the client.)
- Had to back away from a few projects because the existing code
written by someone else was so bad. My estimate for "how long
does it take to do this" was inflated X-fold to accommodate
"...given the current state of the code."

> And anyway, it's only BASIC, it isn't rocket science

> (except for the blokes at JPL that use jBASE that is).

Jim - I'm at JPL occasionally and to my knowledge that's a major
Oracle shop. If I had known they had jBase anywhere I would have
submitted an application years ago. Does anyone from JPL monitor
this list?

Tony Gravagno
Nebula Research and Development
TG@ remove.pleaseNebula-RnD.com
The blog: remove.pleaseNebula-RnD.com/blog
Visit PickWiki.com

[Jim Idle]

Tony G wrote:
>
> Jim - I'm at JPL occasionally and to my knowledge that's a major
> Oracle shop. If I had known they had jBase anywhere I would have
> submitted an application years ago. Does anyone from JPL monitor
> this list?
>

To be fair, I don't know if they still use it, but one of the guys there
wanted to use it for some parts database and we just let them do it for
the kudos - it was just a one man project used by one team.

Jim

[Mike Preece]

I tried to reply via groups.google.com with imbedded responses but the
formatting is so messed up that I gave up.

Suffice to say that I have no argument with you on the validity of
some comments - and in particular those that describe the "why". In
actual fact, the vast majority of comments in the many hundreds of
programs I've seen over the years describe the "what" - like, the
following code does X Y & Z - and the code that follows is often not
as good as it would have to be to stand up on its own. It's like the
comments are being used as a crutch. The comments seem to have given
licence for the developer to go ahead and write thoughtless, shabby
code. It's more difficult to write clear, well-structured code, using
well-chosen variable names, so as to make description superfluous.
It's also right, in my opinion, to assume that the programmers that
will be working on the code in time to come will be... um... not
necessarily as adept as to take "G += (A++)+(-l--)" in their stride,
for example. With that little bit more thought and effort in the first
place life can be so much more pleasant - and uncluttered - for those
that follow.

Looking for common ground... if you've seen the main common block in
some well-known, very large software products, they're sometimes choc-
a-bloc full of cryptic variable names - like one- and two- character
variable names. Their very existance dictates that there must be
comments and/or associated documentation to describe the "what" - or
every techie is going to have to go to a hell of a lot of effort to
trace where each of those variables is initialised, populated and/or
used before he/she has the first clue what they're for... and there is
sometimes a hell of a lot of them and a hell of a lot of code that
uses them. It's a problem that is not easy to solve - although not
impossible - and so the problem perpetuates and grows. That, I *do*
believe, is an example of somewhat shabby work that results in
comments being necessary.

Mike.

On Mar 4, 9:31 pm, Jim Idle <j...@temporal-wave.com> wrote:
> Mike Preece wrote:On Mar 4, 6:10 pm, Simon Verona<si...@dmservices.co.uk>wrote:Agreed about the long term benefits of rewriting! Also whilst we're at it - fire any programmer that uses goto, return   to, undescriptive variable names or seems incapable of writing   comments. Though I did work with a programmer who claimed comments   were unnecessary because the code was"self-documenting"!! Strangely   enough he also was a big "goto" user.... SimonPerhaps controversially,You mean incorrectly.I believe that comments are often a result of somewhat shabby work.This could not be more incorrect. The only way you could contrive to make this correct is if the variable were all called A1 A2 A3 etc and they have to be explained. Variables should be:
> recordCounter
> customerFile
> and so on. Comments are rarely about explaining what the code does. I know what COUNT() does and I can even infer G += (A++)+(-l--) does. Comments are about WHY it does it, and no amount of jiggering about with the code explains things like why are particular algorithm was chosen and so on. We would NEVER have to think twice about these things. And anyway, it's only BASIC, it isn't rocket science (expcet for the blokes at JPL that use jBASE that is).We ought to think twice. Look at the code you've written and see if there are changes you could make to it that would make it self explanatory.I was going to give lots of examples and so on but I don't think there is any point. I think that you must not have ever seen properly documented code. The comments rarely explain the lines of code that are going to run. Comments say things like:

> * Do not be tempted to change this algorithm basing it at 0 as then XYZ is
> * required....
> * The front desk bell captain must be pinged before the bell as the
> * front stufle pump will explode if this happens out of order more than
> * 6 times - doing this here before starting the grunk engine guarantees order
> *
> * We must use a topological sort here as a straight qsort does not account
> * for interdependencies and we must detect dependency cycles here
> *

> * Use dynamic arrays here because....That little bit of extra effort is, in my opinion, better than taking the easy way out by throwing in a comment or two.I am sorry but this is utter rubbish. How is adding comments taking an easy way out - I think that perhaps you experience of other programmers can have been only of relatively mediocre ones. Can I guess that a lot of your code does not have comments in then, and you have self justified this by saying "Ah, now I have formatted it a bit, it is obvious"? This isn't how it works at all. Comments remind you of the thought process you went through 3 years ago to type in the program. If I need comments for something I wrote 3 years ago, then how can I expect someone who has never seen the code to get the gestalt?
> Also, do not forget that sometimes code that is harder to read might be necessary because it is 10X faster and so on.One argument in favour of this approach is that comments can end up misleading or extraneous after a code change.It is part of your job as a programmer to look after the code. If you don't update the comments, then you are not doing your job. The number of times I have heard this crap from programmers is unreal. It is like your mechanic saying "I didn't put in any oil in your car because it will be out of date in 6,000 miles anyway". Just because there are comments does not mean you don't read the code.It'd be easy for a programmer to get in and fix or change something, get the code working as it should, and overlook that the comment should also have been changed.Then he isn't really any good. Good programmers are not hacks who do things that are 'clever' - programming is a profession.And - to add some extra heat to this discussion - GO can sometimes (although very rarely) have its place.Exit to error condition that does not return. That's it.
> Jim