RESOLVE_ALL revisited

[GillesDuvert]

Should REALLY resolve ... ALL

except perhaps some object procedures - to be tested, please report issues .

[rsiddans]

This is great - many thanks for implementing this - it will be really useful.

I notice that it does not behave the same as IDL wrt the round-bracket-ambiguity between functions and arrays.
E.g. if I .run the following and then do resolve_all, it will throw error looking for a function "b.pro" (which IDL does not)...

pro dummy_resolve_all
        b=fltarr(10)
        print,b(2)
end

IDL would only look for b.pro if there was a keyword used in the call (which would confirm that b is a fn not an array).
Obviously this is IDL's fault for allowing the ambiguous brackets. Still if you want the same behaviour as IDL...

I see this can be worked around by using the SKIP keyword (or better by changing to square brackets in the source).

[GillesDuvert]

Thanks for the example, this is a bug indeed. You'll notice that:

 GDL> .compile /tmp/dummy_resolve_all.pro
% Compiled module: DUMMY_RESOLVE_ALL.
GDL> DUMMY_RESOLVE_ALL 
      0.00000

so GDL is not looking for a function when running the procedure. More exactly, it looked for a function, found none, so switched to the next possible interpretation, an array (b) member.
This should be the case also when the resolve_all procedure is called, meaning that resolve_all should not just".compile" but also "run", so to speak.
I open a new issue.

[GillesDuvert]

@rsiddans GDL will work better and even a bit faster if all procedures have been updated to IDL's STRICTARR syntax, i.e., square brackets for arrays, and the interpreter forced globally to the 'new' behaviour with the switch gdl --fussy (each pro/func can be forced with COMPILE_OPT STRICTARR).

Actually the present state of RESOLVE_ALL permits to find those 'old syntax' procedures, as you have observed, (and some typos in the calling of exiting functions!) and normally people can edit these files and correct the syntax. I wonder if it is a good thing to work on #1965 .

[GillesDuvert]

See #2027 and also note the existence of --trace-old-syntax switch described therein.