| Author |
Message |
David J. Dachtera
*nix forums Guru Wannabe
Joined: 21 Mar 2006
Posts: 197
|
|
| Back to top |
|
 |
Paul Sture
*nix forums Guru
Joined: 12 Feb 2005
Posts: 357
|
 Posted: Fri Jun 02, 2006 10:52 am Post subject:
Re: DCL: IF and .AND. logic
|
|
|
JF Mezei wrote:
| Quote: | Paul Sture wrote:
In DCL, I personally prefer CALL to GOSUB, as you have to declare your
subroutine formally with
CALL has a major difference from GOSUB: the subroutine does not, by
default, have the ability to modify local symbols defined in your main
DCL code. I *think* this can be overriden with a SET SYMBOL/SCOPE but am
not sure.
|
But I'm well aware of that fact. Indeed I _want_ to throw away any
temporary variables created in a subroutine, and if I copy a given
subroutine into another procedure*, I _don't_ want it potentially
stamping over any variables in that.
* From a maintenance point of view, it is arguably better to save the
subrouting as another command procedure. |
|
| Back to top |
|
|
Paul Sture
*nix forums Guru
Joined: 12 Feb 2005
Posts: 357
|
| Posted: Fri Jun 02, 2006 10:43 am Post subject:
Re: DCL: IF and .AND. logic
|
|
|
Dave Froble wrote:
| Quote: | Paul Sture wrote:
$ gosub lunch
$ if $status .eq. too_much_spaghetti then goto sleep
Don't you mean GOSUB SLEEP? You do plan on waking, right? :-)
Of course, but it just read better  |
|
|
| Back to top |
|
|
Paul Sture
*nix forums Guru
Joined: 12 Feb 2005
Posts: 357
|
| Posted: Fri Jun 02, 2006 10:37 am Post subject:
Re: DCL: IF and .AND. logic
|
|
|
JF Mezei wrote:
| Quote: | Michael Unger wrote:
being an implicite "ENDSUBROUTINE") you get a new procedure level when
it gets executed -- making it easier to manage the "locality" of
symbols.
Au contraire. It makes for much less obvious management of symbols
because when searching for all occurances of a symbol, you will not know
if that symbol is within a subnroutine or not unless you have a really
big window and see that it is within a subroutine code.
|
On that subject I like to document input and output symbols in comments
at the beginning of a subroutine; subroutine headers will show up in
such a search.
| Quote: | Having a new set of local symbols is a neat concept for DCL, but from my
point of view, it causes more grief than harm since the subroutine
cannot modify mainline symbols unless the symbol(s) you modify are not
only declared globally, but there is also no local declarations.
|
It's simply a matter of discipline, which I happen to like when
programming |
|
| Back to top |
|
|
JF Mezei
*nix forums Guru
Joined: 21 Jul 2005
Posts: 2556
|
| Posted: Thu Jun 01, 2006 7:12 pm Post subject:
Re: DCL: IF and .AND. logic
|
|
|
Michael Unger wrote:
| Quote: | being an implicite "ENDSUBROUTINE") you get a new procedure level when
it gets executed -- making it easier to manage the "locality" of
symbols.
|
Au contraire. It makes for much less obvious management of symbols
because when searching for all occurances of a symbol, you will not know
if that symbol is within a subnroutine or not unless you have a really
big window and see that it is within a subroutine code.
When you look at C subroutines, you alwasy have explicit declarations
"or local symbols" within a subroutine. This is not the case with DCL,
and the use of a SET SYMBOL/SCOPE elsewhere in the DCL program can
completely change the behaviour of your symbols.
Having a new set of local symbols is a neat concept for DCL, but from my
point of view, it causes more grief than harm since the subroutine
cannot modify mainline symbols unless the symbol(s) you modify are not
only declared globally, but there is also no local declarations.
$A = 1
..... <lots of lines of code>
$A == 2
$write sys$output "The value of a is ''A'"
The result will show a value of 1 |
|
| Back to top |
|
|
JF Mezei
*nix forums Guru
Joined: 21 Jul 2005
Posts: 2556
|
| Posted: Thu Jun 01, 2006 6:33 pm Post subject:
Re: DCL: IF and .AND. logic
|
|
|
Paul Sture wrote:
| Quote: | In DCL, I personally prefer CALL to GOSUB, as you have to declare your
subroutine formally with
|
CALL has a major difference from GOSUB: the subroutine does not, by
default, have the ability to modify local symbols defined in your main
DCL code. I *think* this can be overriden with a SET SYMBOL/SCOPE but am
not sure. |
|
| Back to top |
|
|
Dave Froble
*nix forums Guru
Joined: 21 Jul 2005
Posts: 1172
|
| Posted: Thu Jun 01, 2006 5:57 pm Post subject:
Re: DCL: IF and .AND. logic
|
|
|
Paul Sture wrote:
| Quote: | Dave Froble wrote:
Doug Phillips wrote:
Dave Froble wrote:
Michael Unger wrote:
On 2006-05-30 18:47, "Hoff Hoffman" wrote:
[...]
Run-time computed goto operations -- one of the reasons why it
would
be comparatively "fun" to write a compiler for DCL -- are available:
$ GOTO LABEL_'severity'
I don't like "GOTO" at all -- it is much simpler to "go back" using
"GOSUB" and "RETURN" or "CALL" and "EXIT" (or even "EXIT
status-value>".
[...]
Michael
And next we'll have someone wanting to get rid of the BRANCH
instruction
in assembler.
Uh Oh. I smell another religious war, and here I was just about to
GOSUB lunch ;-)
From which I assume you plan to RETURN. :-)
LOL
$ gosub lunch
$ if $status .eq. too_much_spaghetti then goto sleep
|
Don't you mean GOSUB SLEEP? You do plan on waking, right? :-)
| Quote: | The point is, any instruction can be misused. Don't blame GOTO when
some idiot uses it to write practically unreadable code. If there was
no GOTO, he'd find some other way to screw up.
I knew a guy that was so intent on writing 'structured' code that he
used GOSUB to GOTO the exit part of a program.
I've seen that, but also instances where such coding has lead to
recursive calls causing the program to blow up (not necessarily in DCL).
In DCL, I personally prefer CALL to GOSUB, as you have to declare your
subroutine formally with
$label: SUBROUTINE
...
$ENDSUBROUTINE
Compare the results of HELP CALL EXAMPLE and HELP GOSUB EXAMPLE.
And anybody that has written any assembler code understands that the
various forms of BRANCH is how it's all done regardless of HLL
implementations.
True.
|
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486 |
|
| Back to top |
|
|
Michael Unger
*nix forums Guru Wannabe
Joined: 01 Jun 2005
Posts: 109
|
| Posted: Thu Jun 01, 2006 3:46 pm Post subject:
Re: DCL: IF and .AND. logic
|
|
|
On 2006-06-01 11:43, "Paul Sture" wrote:
| Quote: | [...]
In DCL, I personally prefer CALL to GOSUB, as you have to declare your
^^^^^^^^^^^^^^^^^^^^
subroutine formally with
$label: SUBROUTINE
....
$ENDSUBROUTINE
Compare the results of HELP CALL EXAMPLE and HELP GOSUB EXAMPLE.
[...]
|
In addition to the formal declaration needed for a subroutine ("EXIT"
being an implicite "ENDSUBROUTINE") you get a new procedure level when
it gets executed -- making it easier to manage the "locality" of
symbols. (If you have more of them than just a few hundreds ... ;-)
Michael
--
Real names enhance the probability of getting real answers.
My e-mail account at DECUS Munich is no longer valid. |
|
| Back to top |
|
|
Paul Sture
*nix forums Guru
Joined: 12 Feb 2005
Posts: 357
|
| Posted: Thu Jun 01, 2006 9:43 am Post subject:
Re: DCL: IF and .AND. logic
|
|
|
Dave Froble wrote:
| Quote: | Doug Phillips wrote:
Dave Froble wrote:
Michael Unger wrote:
On 2006-05-30 18:47, "Hoff Hoffman" wrote:
[...]
Run-time computed goto operations -- one of the reasons why it
would
be comparatively "fun" to write a compiler for DCL -- are available:
$ GOTO LABEL_'severity'
I don't like "GOTO" at all -- it is much simpler to "go back" using
"GOSUB" and "RETURN" or "CALL" and "EXIT" (or even "EXIT
status-value>".
[...]
Michael
And next we'll have someone wanting to get rid of the BRANCH instruction
in assembler.
Uh Oh. I smell another religious war, and here I was just about to
GOSUB lunch ;-)
From which I assume you plan to RETURN.
|
LOL
$ gosub lunch
$ if $status .eq. too_much_spaghetti then goto sleep
| Quote: |
The point is, any instruction can be misused. Don't blame GOTO when
some idiot uses it to write practically unreadable code. If there was
no GOTO, he'd find some other way to screw up.
I knew a guy that was so intent on writing 'structured' code that he
used GOSUB to GOTO the exit part of a program.
|
I've seen that, but also instances where such coding has lead to
recursive calls causing the program to blow up (not necessarily in DCL).
In DCL, I personally prefer CALL to GOSUB, as you have to declare your
subroutine formally with
$label: SUBROUTINE
....
$ENDSUBROUTINE
Compare the results of HELP CALL EXAMPLE and HELP GOSUB EXAMPLE.
| Quote: | And anybody that has written any assembler code understands that the
various forms of BRANCH is how it's all done regardless of HLL
implementations.
|
True. |
|
| Back to top |
|
|
Dave Froble
*nix forums Guru
Joined: 21 Jul 2005
Posts: 1172
|
| Posted: Thu Jun 01, 2006 2:23 am Post subject:
Re: DCL: IF and .AND. logic
|
|
|
Doug Phillips wrote:
| Quote: | Dave Froble wrote:
Michael Unger wrote:
On 2006-05-30 18:47, "Hoff Hoffman" wrote:
[...]
Run-time computed goto operations -- one of the reasons why it would
be comparatively "fun" to write a compiler for DCL -- are available:
$ GOTO LABEL_'severity'
I don't like "GOTO" at all -- it is much simpler to "go back" using
"GOSUB" and "RETURN" or "CALL" and "EXIT" (or even "EXIT <status-value>".
[...]
Michael
And next we'll have someone wanting to get rid of the BRANCH instruction
in assembler.
Uh Oh. I smell another religious war, and here I was just about to
GOSUB lunch ;-)
|
From which I assume you plan to RETURN. :-)
The point is, any instruction can be misused. Don't blame GOTO when
some idiot uses it to write practically unreadable code. If there was
no GOTO, he'd find some other way to screw up.
I knew a guy that was so intent on writing 'structured' code that he
used GOSUB to GOTO the exit part of a program.
And anybody that has written any assembler code understands that the
various forms of BRANCH is how it's all done regardless of HLL
implementations.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486 |
|
| Back to top |
|
|
dphill46@netscape.net
*nix forums Guru Wannabe
Joined: 20 Sep 2005
Posts: 100
|
| Posted: Wed May 31, 2006 4:56 pm Post subject:
Re: DCL: IF and .AND. logic
|
|
|
Dave Froble wrote:
| Quote: | Michael Unger wrote:
On 2006-05-30 18:47, "Hoff Hoffman" wrote:
[...]
Run-time computed goto operations -- one of the reasons why it would
be comparatively "fun" to write a compiler for DCL -- are available:
$ GOTO LABEL_'severity'
I don't like "GOTO" at all -- it is much simpler to "go back" using
"GOSUB" and "RETURN" or "CALL" and "EXIT" (or even "EXIT <status-value>".
[...]
Michael
And next we'll have someone wanting to get rid of the BRANCH instruction
in assembler.
|
Uh Oh. I smell another religious war, and here I was just about to
GOSUB lunch  |
|
| Back to top |
|
|
Dave Froble
*nix forums Guru
Joined: 21 Jul 2005
Posts: 1172
|
| Posted: Wed May 31, 2006 4:40 pm Post subject:
Re: DCL: IF and .AND. logic
|
|
|
Michael Unger wrote:
| Quote: | On 2006-05-30 18:47, "Hoff Hoffman" wrote:
[...]
Run-time computed goto operations -- one of the reasons why it would
be comparatively "fun" to write a compiler for DCL -- are available:
$ GOTO LABEL_'severity'
I don't like "GOTO" at all -- it is much simpler to "go back" using
"GOSUB" and "RETURN" or "CALL" and "EXIT" (or even "EXIT <status-value>".
[...]
Michael
|
And next we'll have someone wanting to get rid of the BRANCH instruction
in assembler.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486 |
|
| Back to top |
|
|
Paul Sture
*nix forums Guru
Joined: 12 Feb 2005
Posts: 357
|
| Posted: Wed May 31, 2006 1:28 am Post subject:
Re: DCL: IF and .AND. logic
|
|
|
Michael Unger wrote:
| Quote: | On 2006-05-30 18:47, "Hoff Hoffman" wrote:
[...]
Run-time computed goto operations -- one of the reasons why it would
be comparatively "fun" to write a compiler for DCL -- are available:
$ GOTO LABEL_'severity'
I don't like "GOTO" at all -- it is much simpler to "go back" using
"GOSUB" and "RETURN" or "CALL" and "EXIT" (or even "EXIT <status-value>".
|
But before GOSUB, CALL etc existed (prior to V4.0 ?), one way of using a
common piece of code was something like:
$ return_label = "A100"
$ goto common_code
$A100:
....
$common_code:
.... do whatever ...
$ goto 'return_label' |
|
| Back to top |
|
|
Michael Unger
*nix forums Guru Wannabe
Joined: 01 Jun 2005
Posts: 109
|
| Posted: Tue May 30, 2006 8:43 pm Post subject:
Re: DCL: IF and .AND. logic
|
|
|
On 2006-05-30 18:47, "Hoff Hoffman" wrote:
| Quote: | [...]
Run-time computed goto operations -- one of the reasons why it would
be comparatively "fun" to write a compiler for DCL -- are available:
$ GOTO LABEL_'severity'
|
I don't like "GOTO" at all -- it is much simpler to "go back" using
"GOSUB" and "RETURN" or "CALL" and "EXIT" (or even "EXIT <status-value>".
Michael
--
Real names enhance the probability of getting real answers.
My e-mail account at DECUS Munich is no longer valid. |
|
| Back to top |
|
|
Michael Unger
*nix forums Guru Wannabe
Joined: 01 Jun 2005
Posts: 109
|
| Posted: Tue May 30, 2006 7:17 pm Post subject:
Re: DCL: IF and .AND. logic
|
|
|
On 2006-05-29 23:01, "Norman Lastovica" wrote:
| Quote: | in this case, I believe that you could just use
the "built-in" $SEVERITY symbol.
|
If *only* the severity level is to be checked -- then yes. But in most
cases it is desirable to get more detailled information if "something
went wrong" and therefore $STATUS has to be saved before.
| Quote: | Michael Unger wrote:
[...]
I'd prefer a construct like:
$ status = $STATUS
^^^^^^^^^^^^^^^^^^
$ severity = status .AND. 7
$ IF severity .EQ. 0 THEN WRITE SYS$OUTPUT ...
$ IF severity .EQ. 1 THEN ...
$ ...
|
Michael
--
Real names enhance the probability of getting real answers.
My e-mail account at DECUS Munich is no longer valid. |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Forum index
»
Not Unix
»
VMS
