declare hash hh(dataset: 'dsname(dsoption=( ' ) syntax confusion with missing parenthesis

[nayon]

(New here and just learning SAS, so please let me know if I'm posting inappropriately.)

I wonder if/what I'm missing about SAS syntax when declaring data step hash object using dataset: 'somedataset( somedatasetoptions )'. SAS does not complain about a missing closing parenthesis, where the parentheses are enclosing the data set option such as keep= or where=() 

As in:

declare hash ...

hashname( dataset: 'dsname(keep=var1 var2'  )   ....runs fine, but it probably should be  ...

hashname( dataset: 'dsname(keep=var1 var2)'  )    ...where the data set keep= option is enclosed in <<open paren>> keep=var1 var2 <<close paren>>

See example code below. Note the "declare hash ..." statement. I'm just curious -- am I missing a concept of syntax that's important? 

Comments? Thanks. 

data fib; input i fib_i crap; cards;
1  1  9
2  1  9
3  2  9
4  3  9
5  5  9
6  8  9
7  13 9
8  21 9
9  34 9
10 55 9
11 89 9
;
run;

data _NULL_; length i fib_i 8;
/***  declare hash fib ( dataset: 'fib(keep=i fib_i)'  ); ***/
      declare hash fib ( dataset: 'fib(keep=i fib_i '  );  /*seems odd that SAS is ok with the missing closing ')' after fib_i*/
      fib.definekey('fib_i'); fib.definedata('i'); fib.definedone(); call missing(i, fib_i);
      do fib_i=1 to 100;
        if ~fib.find() then put i= fib_i=; 
      end;
      stop;
run;

and I cannot imagine the log helps, but here's a copy paste from SAS Studio log

1 OPTIONS NONOTES NOSTIMER NOSOURCE NOSYNTAXCHECK;

68

69

70 data _NULL_; length i fib_i 8;

71 /*** declare hash fib ( dataset: 'fib(keep=i fib_i)' ); ***/

72 declare hash fib ( dataset: 'fib(where=(1) ' ); /*SAS is ok with the missing closing ')' after fib_i*/

73 fib.definekey('fib_i'); fib.definedata('i'); fib.definedone(); call missing(i, fib_i);

74 do fib_i=1 to 100;

75 if ~fib.find() then put i= fib_i=;

76 end;

77 stop;

78 run;

NOTE: There were 11 observations read from the data set WORK.FIB.

WHERE 1 /* an obviously TRUE WHERE clause */ ;

i=1 fib_i=1

i=3 fib_i=2

i=4 fib_i=3

i=5 fib_i=5

i=6 fib_i=8

i=7 fib_i=13

i=8 fib_i=21

i=9 fib_i=34

i=10 fib_i=55

i=11 fib_i=89

NOTE: DATA statement used (Total process time):

real time 0.00 seconds

user cpu time 0.00 seconds

system cpu time 0.01 seconds

memory 1202.84k

OS Memory 22692.00k

Timestamp 08/02/2023 06:02:55 AM

Step Count 215 Switch Count 0

Page Faults 0

Page Reclaims 337

Page Swaps 0

Voluntary Context Switches 0

Involuntary Context Switches 0

Block Input Operations 0

Block Output Operations 0

79

80

81

82

83 OPTIONS NONOTES NOSTIMER NOSOURCE NOSYNTAXCHECK;

93

[Tom]

The problem with the HASH object syntax is that much of it cannot be validated by the SAS compiler when it is defining the data step since to the compiler they are just strings.

So to the data step compiler this line:

declare hash fib ( dataset: 'fib(keep=i fib_i '  );

Is valid.  The DECLARE HASH statement needs an name for the new object, fib, and then some options in quotes.

The dataset: option needs a quoted string and that is there.  But the compiler cannot check if the quoted string is valid or not.

What seem strange is that whatever method it is that the HASH object is using the dynamically open a dataset and read them seems to not care that the closing parentheses are present.

You should probably report this to SAS as a BUG.

Here is an experiment you can try to see if this result extends to other dynamic attempts to open a dataset.  Try using one the those unbalanced dataset option lists with the OPEN() function and see if it causes errors.

[Quentin]

Agree, that is surprising behavior, and looks buggish.  SAS was also happy to add two missing close parens:

declare hash fib ( dataset: 'fib(keep=i fib_i rename=(fib_i=Q' ); 

And will ignore garbage text after the specification:

declare hash fib ( dataset: 'fib(keep=i fib_i ) blah blah'  ); 

[nayon · Accepted solution]

UPDATE -- Hash dataset declaration with unbalanced parentheses in dataset option list. 

Per suggestion of Tom, I reported this "bug/oddity" issue to SAS support with reference to this posting; they responded back: "Thanks for reporting this."

SAS may or may not choose to address this issue as they wish. That's it, done, case closed from my perspective.

If someone manages to contrive a related example where this 'oddity' results in unintended unexpected behavior, then it's potentially a dangerous bug and would be worth noting here and to SAS support.