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: InterpreterSeverity: 1 - Wish
Priority: 5 - NormalItem Group: Matlab Compatibility
Status: ConfirmedAssigned to: None
Originator Name: Open/Closed: Open
Release: devOperating 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 Jump to the original submission)

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?

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:

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

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?

Or if we use perl regexp

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.

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.*;
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>
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,

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

Rik <rik5>
Project Administrator

 

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

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items

Digest:
   bug dependencies.

Items that depend on this one: None found

 

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

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

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follows 1 latest change.

    Date Changed By Updated Field Previous Value => Replaced By
    Tue 08 Aug 2017 04:43:48 PM UTCrik5Dependencies-=>Depends on bugs #47753

    Back to the top


    Powered by Savane 3.1-cleanup1