Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Bug or feature? Unexpected behavior of syntax command

    I have noticed a strange behavior of the syntax command. In the following example, the option int() expects an integer argument. Surprisingly, if I call the command with a non-integer value in int(), it does not abort with an error message but treats this option as one of the additional options to be placed in the local macro `options'. In my view, this is very strange. Does anybody have any insights whether this is an intended feature?

    Code:
    capture program drop testprog
    
    program define testprog
        syntax , [INT(integer 1) *]
        display "INT: `int'"
        display `"*: `options'"'
    end
    
    testprog , int(0.5)
    https://www.kripfganz.de/stata/

  • #2
    Interesting case. I would not have expected this behavior. I see that you could argue that * captures anything after the comma that cannot be matched to the listed options. However, given that

    Code:
    capture program drop testprog
    
    program define testprog
        syntax , [FOO(numlist) *]
        display "FOO: `foo'"
        display `"*: `options'"'
    end
    
    testprog , foo("bar")
    produces

    Code:
    foo() invalid -- invalid numlist
    r(121);
    I'd say the behavior is inconsistent and, thus, a bug -- either in how interger is handled or in how numlist is handled.

    Edit: I am aware that numlist differes from (optional) integer or real in that the latter must provide a default value. I do not see how that would be relevant to the consistency argument.
    Last edited by daniel klein; 21 Jul 2022, 06:08.

    Comment


    • #3
      I think (!) it is actually a "feature" because Stata creates the local "int" with the default value 1. If it does not find the option int, it puts everything else into "*". If you do not give Stata the default 1, the program should abort with an error. So in a sense this behaviour might be desired

      This reminds me a bit to the behaviour that Stata accepts arguments and/or options for program with the same abbreviation, see for example the program below:

      Code:
      capture program drop testprog
      
      program define testprog
          syntax , [LONG(integer 1) LONGstr(string) LONGindex *]
          display "Integer: `long'"
          display "String: `longstr'"
          display "Optional: `longindex'"
          display "Rest: `options'"
      end
      Gives the user 3 options to define the option long.

      Some examples would be:

      Code:
      .
      . testprog , long(2)
      Integer: 2
      String:
      Optional:
      Rest:
      
      . testprog , long("abc")
      Integer: 1
      String: abc
      Optional:
      Rest:
      
      . testprog , long
      Integer: 1
      String:
      Optional: longindex
      Rest:
      
      . testprog , long long(0.5) long(abs)
      Integer: 1
      String: 0.5
      Optional: longindex
      Rest: long(abs)
      
      . testprog , long long(2) long(abs)
      Integer: 2
      String: abs
      Optional: longindex
      Rest:
      I think the case
      Code:
      testprog , long long(0.5) long(abs)
      is interesting because it treats 0.5 as a string.

      Comment


      • #4
        The response I received from Stata's technical support is basically in line with what Jan said. I guess we just need to be careful with syntax parsing.
        https://www.kripfganz.de/stata/

        Comment

        Working...
        X