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

 
 

bug #51688: support for "import" keyword

Submitter:  Rik <rik5>
Submitted:  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
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

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

Anonymous
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>
Group 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>
Group 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>
Group 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)
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).

John W. Eaton <jwe>
Group 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>
Group Member
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
=>
s/(?<!\.)Map\b/containers.Map/g



Rik <rik5>
Group 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>
Group 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.*;
  end
  bar ();  %% global function bar?  pkg.bar?  Who knows?
end

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>
Group 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>
Group 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>
Group Member
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>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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>
Group administrator

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items

Digest:
   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)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group 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.13-4448.
    Corresponding source code