Enable Imports (#3)

[MatthewSH]

In an attempt to relieve @adapap from all the work, here's my attempt at implementing this functionality referenced in #3.

While in the issue I talk about discouraging nesting imports, I ended up adding the ability to have them. This came from my conversation with Adam regarding it and it came to mind how having a recursive import function could be very useful...even in my own projects.

I did add a warning to the command as well, although it should work perfectly fine...it should be used with caution and still needs more testing. Although, in theory, it should work.

To enable imports, please use the --enable-imports flag. If you do not use this flag and try to use OWScript on a file that is using #import, you will have errors thrown back because the transpiler doesn't know what to do with them.

Todo

• [x] Test nesting modules to a deeper amount (I tested to a depth of 7-8 and reference a parent module the same amount up...works perfectly fine)

[MatthewSH]

Debating on this...but what if instead of returning text...we return an object/array that would contain a list of all imports...basically a way to track duplicate imports and instead of repasting them...remove them completely as they were previously defined in the script.

Thoughts @adapap?

[adapap]

Debating on this...but what if instead of returning text...we return an object/array that would contain a list of all imports...basically a way to track duplicate imports and instead of repasting them...remove them completely as they were previously defined in the script.

Thoughts @adapap?

@MatthewSH The way i'm looking to integrate this is to inject the the parse tree resulting from the child into the parent import. The process of transpiling involves tokenizing the input (lexing), structuring/ordering it (parsing), and understanding (interpreting/compiling). If we intercept the parsed state, we can catch errors such as undefined variables during the final stage of transpiling.

Edit: But to answer your question, whenever an import node is recognized, it can keep track of the absolute? path to that file so that something like lib/child.owpy will not be duplicated through ../child.owpy from another directory.

[MatthewSH]

In regards to how you are thinking about integrating it, I’ll leave that up to you for. I’ll give you permission to write to my repo so you can make any changes needed. I’ve never worked with python prior to this.

Other than that, basically yeah. Parsing the absolute path and making sure its not duplicated. Only thing I could see happening is undefined functions, but the likelyhood of that I believe is slim. Especially if you attempt to import it in every file you use.