[Octave-bug-tracker] [bug #51688] support for "import" keyword

[John W. Eaton]

Follow-up Comment #13, bug #51688 (project octave):

Yes, text substitution is tempting, but does this mean that the resolution of
imported +package names depends on the value of the load path when a function
is first parsed?  I'm pretty sure that's not the way function resolution works
when there are not import statements present.

Also, then does eval break import?


function foo (lookout)
  import pkg.*;
  eval (lookout);
  sin (2)
end

foo ('sin = [42, 13]')


Does this get 'pkg.sin (2)' (if +pkg/sin.m exists in the path) or does it
display 13?  If pkg.sin is not in the path, does it display 13 or 0.9093?

What about things like this:


function foo (f, d1, d2)
  orig_dir = cd ();
  eval (sprintf ('%s %s', f, d1));
  bar ();
  cd (orig_dir);
  eval (sprintf ('%s %s', f, d2));
  bar ();
  cd (orig_dir);
end
foo ('cd', 'da', 'db')


assuming separate functions 'da/bar.m' and 'db/bar.m'?  In this case, I don't
think the definition of bar can be found when the function foo is first
parsed.  So what happens if an import statement is added to a function like
this?  Does the result depend on the value of the load path when the function
is first parsed?  What happens if the load path is later changed?

Finally, if, as the docs say, import is handled before evaluating the
conditional, then it is sort of like a preprocessor directive.  Is there any
warning for this kind of usage?  In this sense, import sort of looks like a
keyword, but it is apparently not one in Matlab (documentation for iskeyword
says it is not, and I assume you can use it as a variable or function name).

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?51688>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/