Submodule resolution failed

[mtshiba]

Describe the bug?

Suppose we have bar module in the foo module and func function in the bar module.

Reproducible code

foo = pyimport "foo"
bar = foo.bar
bar_ = pyimport "foo/bar"

bar.func # No. 1
bar_.func # No.2
foo.bar.func # No.3

Expected result

passed

Actual result

Only No.1 fails to compile.

Additional context

The signature of the pyimport function has so far been defined just as a dependent function, but perhaps it should be a compiler built-in magic function.

foo = import “foo” # : Module(“foo”)
# ↓
foo = import “foo” # : Module(“packagename/foo”) 

Erg version

0.6.25

Python version

None

OS

None

[toddlerer]

Perhaps a related example in other languages is ES Modules (recently adopted in JavaScript), where some restrictions, such as limiting import statements to the top level only, make static analysis easier and facilitate tree shaking and bundling. Erg currently treats import a normal function, similar to the CommonJS module system (used in the old Node.js).
For example, this article is helpful.

Also, I don't think it is intuitive to write the variable names of the imported items first as an order of thought. (I understand that this could be mitigated by magic completion and auto import functions by the editor)

So, how about having a different syntax for import with the intention that it is not a normal function?
For example, the syntax is as follows

import “./foo” as foo
pyimport “core/api" as api
pyimport “core/api” use { DataFrame!; Series! as S!; Index;}

ES Modules Specifications: https://tc39.es/ecma262/#sec-modules

[mtshiba]

I think only assignment operators should be able to introduce variables. Because it is simpler.

But, in many languages the symbols to import are placed on the right side of the module name (Zig is different), so this may be a resistant syntax.

from foo import bar, baz

I came up with the idea of adopting the right-assignment syntax introduced in Ruby and other languages.

x = 1
# same as
1 => x

Erg already uses =>, so it would be another operator (like =:), but since this is just a syntax sugar for =, it is relatively easy to implement. And it can be used in places other than import.

{sin; cos} = pyimport "math"
pyimport "math" =: {sin; cos}
x = 1
1 =: x
rec = {x = 1; y = 2}
rec =: {x; y}

[toddlerer]

Indeed, it seems that Erg is emphasizing syntactic simplicity.
The idea of using the right-assignment syntax for the import statement, as seen in R or Ruby, is an interesting one for maintaining simplicity in syntax. Additionally, the right-assignment syntax pairs well with method chains or pipeline operators, where the data flow is more prominent.

On the other hand, everything that can be done with the right-assignment syntax can also be done with the standard = syntax, and having multiple ways to do the same thing can be a source of confusion (though this could be restricted with a linter). Moreover, there's also the potential for limiting future expandability. For example, it might make it difficult to introduce attribute-like features that are attached after the data, such as TypeScript's satisfies operator.

Considering these points, while it's worth examining the right-assignment syntax, at present I personally believe that the benefits are few, and it's not a feature worth adding just for the import syntax. Similarly, if we prioritize the language's simplicity, my idea of introducing a different syntax for imports might also be better left unimplemented. Even widely-used JavaScript (ES Modules) has the symbols being imported on the left side, and I haven't heard others complain about that.

[mtshiba]

I see. At this time, this is not a high priority issue, so we will discuss this again in the future if we need to.

[mtshiba]

#492 may resolve import syntax problem.