1748171 Members
4150 Online
108758 Solutions
New Discussion юеВ

Re: Silly DCL question

 
SOLVED
Go to solution
Jimson_1
Frequent Advisor

Silly DCL question

Hi,

Silly question here...
And all because I need to justify my review comments on some DCL script that someone changed...

In DCL, why bother having the comparison operators .ne. and .nes. when DCL converts everything to the same type before the comparison anyway?

For example, all the following work:

$ IF 1 .EQS. "1" THEN WRITE SYS$OUTPUT "EQUAL"
EQUAL

$ IF 1 .EQ. "1" THEN WRITE SYS$OUTPUT "EQUAL"
EQUAL

$ IF "1" .EQ. 1 THEN WRITE SYS$OUTPUT "EQUAL"
EQUAL

$ IF "1" .EQS. 1 THEN WRITE SYS$OUTPUT "EQUAL"
EQUAL
6 REPLIES 6
Hein van den Heuvel
Honored Contributor
Solution

Re: Silly DCL question

Try

$ IF 01 .EQ. "01" THEN WRITE SYS$OUTPUT "EQUAL"

vs

$ IF 01 .EQS. "01" THEN WRITE SYS$OUTPUT "EQUAL"

hth,
Hein.
Jimson_1
Frequent Advisor

Re: Silly DCL question

Excellent.
Thanks.
Unfortunately I can only give you 10 points.
You deserve twice as many.

Regards

JamesP
Jess Goodman
Esteemed Contributor

Re: Silly DCL question

Another example showing what can happen if you use the wrong comparison operator:

$ IF "abcdef" .eq. "GHIJKL" THEN WRITE SYS$OUTPUT "same string"
same string
I have one, but it's personal.
Jimson_1
Frequent Advisor

Re: Silly DCL question

Thanks, any more examples?
John Gillings
Honored Contributor

Re: Silly DCL question

JamesP,

Not a silly question at all!

Jess's example shows a very common error in DCL code. I've been bitten by that one many times!

"when DCL converts everything to the same type before the comparison anyway?"

This is the source of the trouble! It doesn't convert to a common type, instead it trys to guess the approprite typefor each symbol from context. Implicit conversions can, and often do guess the wrong thing and give unexpected results. (try Basic sometime - a simple line of code can often generate a bewildering number of unexpected conversions). Another place this causes trouble in DCL is in string arithmetic:

$ x=1
$ s1="A"
$ s2="B"
$ s3=s1+s2
$ s4=s1+s2+x

The presence of a single numeric symbol changes the whole expression to numeric, so the value of s4 is (numeric) 1.

I find it safer to make all conversions explicit, using F$INTEGER and F$STRING in anything but the most simple instances. Code is more verbose, but also more robust.
A crucible of informative mistakes
Jess Goodman
Esteemed Contributor

Re: Silly DCL question

John,

I find that using F$INTEGER(SYMBOL) in an expression (instead of just SYMBOL) is pointless, because F$INTEGER does not give an error if SYMBOL is not a numeric string.

Just like an implicit conversion, F$INTEGER converts non-numeric strings to either 0 or 1 based on the first character.

So instead of code like this:
$ I = F$INTEGER(INPUT)

I use:
$ I = 'INPUT'
which at least gives a warning message on non-numeric strings (assuming the value of INPUT is not a symbol name). That way you can eveen test if the conversion failed with:
$ IF (.NOT.$STATUS) THEN SAY "bad input"

Of course even better code would be to first test using F$TYPE(INPUT) and then convert it, but that is an extra step to add to the code.
I have one, but it's personal.