Import statements with module instantiation should not trigger an error message

[nad]

An import statement of the form import M args triggers the following error message:

An import statement with module instantiation does not actually import the module.  This statement achieves nothing.  Either add the `open' keyword or bind the instantiated module with an `as' clause.

However, if M contains instances, then this kind of import statement actually makes sense.

[andreasabel]

Ok, I commented out the line in the parser that raised the error.

[UlfNorell]

I put back the check. With the fixes to #1913 and #2489 it no longer makes sense to not open or name the module.

[nad]

Please document this change.

[nad]

Previously I could write

import M args

in order to bring instances into scope. Now I have to write something like

import M args as Dummy

Can someone please motivate this change?

[nad]

The situation would be slightly better if I could write _ instead of inventing dummy names:

import M args as _

However, this doesn't work (#3457).

[UlfNorell]

Can someone please motivate this change?

You have filed most of the "instances should only be used if in scope" issues (for instance #1265 and #1913). Clearly if you just say import M args (or import M args as _) they wouldn't be in scope.

[nad]

OK, I think that's a step in the right direction.

I do think that the following code is too ugly:

import M args as Dummy₁
import N args as Dummy₂

However, the reason that I have modules with nothing but instances is that instances became available for instance resolution so easily before. I wonder if I would have used a different design if the new rules had been in place when I wrote my code. (I don't feel like redesigning it now.)

[jespercockx]

Wait, now I'm confused. Doesn't 'in scope' for instance arguments also include things that are only in scope under their qualified name? So then import M args should make all instances in M available for instance search? Quoting @UlfNorell from #1265:

In your example, however, the instance is in scope (as Instance.r). It's
quite common that you use modules qualified to avoid polluting the namespace.
It would be annoying if you were forced to make all instances available in the
top-level scope for them to be used.

(#1913 is about private instances which are really not in scope, not even under a qualified name.)

[jespercockx]

Oh, I misunderstood. This issue is only about modules that are applied to arguments at the place where they're imported. I anyway never parametrize the top-level module in a file so I don't care much about how this works.