Does GDL do the right thing when parsing pro files? (philosophical question)

[GillesDuvert]

IDL defines all tokens it thinks are variables during the parsing of procedures. GDL defines them only when it actually needs them. Consider the following:

pro tutu, valid=valid
  help
end

pro toto
  print, "calling a procedure with an undefined keyword"
  tutu,valid=invalid
  print, "calling a procedure with a !NULL keyword"
  null=!NULL
  tutu,valid=null
  print, "calling a procedure with a defined keyword"
  valid=1
  tutu,valid=valid
end

If you save this as 'toto.pro', and run it, in the first case ('absolutely not defined') IDL knows that valid exist (and is undefined), GDL does not know about it at all.

IDL> toto
% Compiled module: TOTO.
calling a procedure with an undefined keyword
% At TUTU                2 /tmp/toto.pro
%    TOTO                8 /tmp/toto.pro
%    $MAIN$          
VALID           UNDEFINED = <Undefined>
Compiled Procedures:
    $MAIN$  TOTO        TUTU
GDL> toto
% Compiled module: TOTO.
calling a procedure with an undefined keyword
% At TUTU                 2 /tmp/toto.pro
     TOTO                 8 /tmp/toto.pro
     $MAIN$          
Compiled Procedures:
$MAIN$ TOTO TUTU 

Cannot see how this different behaviour could not lead to some discrepancies in the handling of (nested) procedures. Defining a variable at compile time, even if 'undefined', restricts the creation of a C++ GDL object (which is slow) to the parsing stage, so alleviates the burden during the execution? Would GDL be faster in this case?

[jtappin]

Is it any more than what help reports? One situation where I thought it could make a difference would be if there was a call to scope_varfetch that accessed the undefined variable without the /enter key e.g.:

pro setit

  (SCOPE_VARFETCH('und', LEVEL = -1)) = 'text'

end

pro udefv

  setit

  help

  und = 1
end

But, it seems OK.