bugGNU Octave - Bugs: bug #51688, support for "import"...


bug #51688: support for "import" keyword

Submitted by:  Rik <rik5>
Submitted on:  Tue 08 Aug 2017 04:00:15 PM UTC  
Category:  Octave Function Severity:  1 - Wish
Priority:  5 - Normal Item Group:  Feature Request
Status:  Confirmed Assigned to:  None
Originator Name:  Open/Closed:  Open
Release:  dev Operating System:  Any

Add a New Comment (Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

Tue 08 Oct 2019 10:32:07 AM UTC, comment #17: 

When will a Matlab compatible implementation be available which includes also the "handle" keyword and the .* funcitonality

Wed 09 Aug 2017 11:11:44 PM UTC, comment #16: 

More data has come in from the Maintainer's List.  'import' is definitely not a keyword in the language, and is just a built-in function that can be overridden in the language.

That probably gives some clues about the implementation.

Rik <rik5>
Project Administrator
Wed 09 Aug 2017 09:36:23 PM UTC, comment #15: 

I'm fine with doing the minimum necessary.  I just asked some discovery questions about import on the Maintainer's List.

Rik <rik5>
Project Administrator
Wed 09 Aug 2017 09:29:09 PM UTC, comment #14: 

I also see from https://www.mathworks.com/help/matlab/ref/import.html that "import pkg.*" is discouraged, so I suppose we could simply not implement that feature and still provide the rest.  It's that use of import that would be the most trouble to implement anyway.

John W. Eaton <jwe>
Project Administrator
Wed 09 Aug 2017 09:23:18 PM UTC, comment #13: 

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)

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);
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).

John W. Eaton <jwe>
Project Administrator
Wed 09 Aug 2017 09:07:14 PM UTC, comment #12: 

Someone could test whether newly created functions are automatically imported if they match a previously executed import command.

For example

>> mypackage.func1  %% let's say this is an existing function
>> import mypackage.*
>> func1   %% should do the same as above

%% now create a new function +mypackage/func2.m
>> func2   %% does this find the new function?

Mike Miller <mtmiller>
Project Administrator
Wed 09 Aug 2017 08:40:40 PM UTC, comment #11: 

Does the Limitation mentioned in the documentation hint that this may be done more simply through a pre-processor?

What if the import statement was similar to the #define of the C preprocessor?

import containers.Map
#define Map containers.Map

Or if we use perl regexp

import containers.Map

Rik <rik5>
Project Administrator
Wed 09 Aug 2017 08:30:09 PM UTC, comment #10: 

No need to overestimate the prowess of the Mathworks engineers.  The documentation (https://www.mathworks.com/help/matlab/ref/import.html) says that the import word must never be used in conditionals.

Limitations: Do not use import in conditional statements inside a function. MATLAB preprocesses the import statement before evaluating the variables in the conditional statements.

Things really would be mind-blowingly complex if an identifier like 'sin' could point willy-nilly at different implementations depending on a runtime variable like flag.

Rik <rik5>
Project Administrator
Wed 09 Aug 2017 07:00:55 PM UTC, comment #9: 

Rik: Symbols are just tree_identifier objects.  That's all the parser creates for them.  The final binding of a symbol doesn't happen until evaluation.  It must be this way to handle changes in loadpath and other things that can happen dynamically.  I think it should also be possible to do things like this:

function foo (flag)
  if (flag)
    import pkg.*;
  bar ();  %% global function bar?  pkg.bar?  Who knows?

and the particular "pkg" that you get could further depend on the  contents of the loadpath (there could even be more than one "+pkg" directory; which one you find depends on loadpath order).

Mike: No, I haven't given that much thought.  I would just be happy to have it working for Octave +packages.

Meta comment:  This language blows.

John W. Eaton <jwe>
Project Administrator
Wed 09 Aug 2017 06:35:50 PM UTC, comment #8: 

I checked in an import.m file which has a docstring and emits an error if it is used (http://hg.savannah.gnu.org/hgweb/octave/rev/aa0c6708046a).  This is just a placeholder while things are worked out.

Rik <rik5>
Project Administrator
Wed 09 Aug 2017 06:16:39 PM UTC, comment #7: 

Also, have you thought about how to handle importing scopes from extension languages, such as Java, Python, Windows COM objects? Would there be a way for an oct file to hook into the import mechanism to allow names to be looked up in its own package name resolution system?

Mike Miller <mtmiller>
Project Administrator
Wed 09 Aug 2017 06:16:35 PM UTC, comment #6: 

When a function is parsed, what sort of object is put in for a call to an external function?  I'm trying to figure out whether something like "sin" is converted to an executable object, in which case the overhead of checking the import list only happens once when the function is parsed and is probably okay.  Or does the symbol resolution happen every single time function is evaluated, and perhaps more than that if the symbol like "sin" is used in a for loop?

This is a hack, but I've been experimenting with "source".  This parses and enters the function into the symbol table which then makes it available for execution without the package/namespace qualifiers.  So "source absolute_path_to_+package/myfcn.m" is roughly equivalent to "import package.myfcn".  It does have some disadvantages.  It doesn't work for classes, and it seems to make a command-line version of the function present even in the base workspace.

Rik <rik5>
Project Administrator
Wed 09 Aug 2017 05:23:21 PM UTC, comment #5: 

I've looked at this feature in the past.  Maintaining the list of imported package names should be fairly easy.  Even looking up names given an import list should not be too hard.  But is there some simple trick to avoid a performance penalty for every symbol lookup when a scope has a non-empty import list attached to it?

John W. Eaton <jwe>
Project Administrator
Tue 08 Aug 2017 04:42:22 PM UTC, comment #4: 

@jwe: Oh, that's fine.  I wasn't sure exactly what Matlab was doing.  Which folder should it go in?  Seems like one of general, path, or pkg would be logical.

Rik <rik5>
Project Administrator
Tue 08 Aug 2017 04:36:27 PM UTC, comment #3: 

I had ¨import" as a feature request in bug #47753 so you can close it there.

Guillaume <gyom>
Tue 08 Aug 2017 04:26:36 PM UTC, comment #2: 

Rik: with dca84dfe167f you added "import" as a keyword in the language, but I think it is just a function in Matlab, not a keyword.  So we should probably also be able to handle the import functionality as a function in Octave without needing to reserve another word.

John W. Eaton <jwe>
Project Administrator
Tue 08 Aug 2017 04:07:48 PM UTC, comment #1: 

To get started on an implementation, I added "import" to the list of Octave keywords in this cset (http://hg.savannah.gnu.org/hgweb/octave/rev/dca84dfe167f).

Now, iskeyword ("import") returns true.  However, the parser doesn't do anything except produce a syntax error if you try to use it.  Probably the next step would be to have the parser produce an error message along the lines of "error: keyword "import" is not yet supported".

Rik <rik5>
Project Administrator
Tue 08 Aug 2017 04:00:15 PM UTC, original submission:  

To continue Matlab compatibility, Octave needs support for the import keyword which allows a programmer to bring symbols from a different scope into the local scope.  See https://www.mathworks.com/help/matlab/ref/import.html.

Although functions can always be used with their fully qualified names, it can be tedious to do so.  For example,

s = java.lang.String ("Hello World");

If Java strings are going to be used throughout the code it makes the code more readable if the symbol can be imported.

import java.lang.String;
s = String ("Hello World");

Rik <rik5>
Project Administrator


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items

   bug dependencies.

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by gyom (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by rik5 (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.




    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-08-11 mtmiller Carbon-CopyRemoved 80942 => -
    2019-08-11 mtmiller CategoryInterpreter => Octave Function
        Item GroupMatlab Compatibility => Feature Request
    2017-08-08 rik5 Dependencies- => Depends on bugs #47753

    Back to the top

    Powered by Savane 3.5