Future: feature idea: "use Module as M"

[cassella]

to allow fully-qualified references to Module's symbols
through the name M. (e.g., reference Module.x as M.x)

[cassella]

I don't have a need, or even a use case, for this. I just thought it'd be neat.

Feel free to reject the PR if it doesn't seem useful or worthwhile.

[ronawho]

👍 I really like this suggestion/approach

[bradcray]

I was originally intrigued by this proposal (in the "maybe this is what we've been seeking" sense), but thinking about it some more, I'm not sure that it's the right way to say "make me use fully qualified names" -- though I think it could still be a supported feature as a way of avoiding typing a long module name.

Specifically, in the case where I prefer the original module name to creating a new alias to it, it seems like I should be able to type:

use M as M;

rather than being required to type:

use M as aliasForM;

Yet, 'use M as M' seems like just a roundabout way to write 'use M' and therefore seems like it should behave the same (i.e., should not suggest a requirement to use fully qualified names). By extension, 'use M as aliasForM' seems like it's saying "permit me to call 'M' 'aliasForM' but it doesn't actually suggest (to me) anything different about the names needing to be fully qualified. So for that, I still think that, given the current definition of 'use', the requirement to fully qualify should be specified differently than 'as'. E.g., perhaps:

use M qualified;

or:

use M only qualified;

where 'qualified' is a keyword (and where the two other new-keyword-free approaches we've discussed are:

use M only ;

and:

use M except *;

Two other notes:

1. @lydia-duncan put together a nice table at one point listing Haskell 'import' variants and the closest equivalents in Chapel (when available) which might be interesting to look through as further food for thought in this area.

2. There's also been a proposal to introduce an 'import' statement alongside 'use' which would have more of the "don't support unqualified references by default" semantics, optionally with the intention to retire 'use' over time (where the two main reasons not to keep both would be (a) to avoid confusion over having two ways to do very similar things and (b) intuitively, to me at least, the word 'import' more naturally implies "make symbols directly available to me in an unqualified way in this scope" whereas 'use' more naturally implies 'use the module, but don't bring its symbols into scope" -- so having both while also having them do the opposite of what their English meaning would seem to imply seems arguably worse than having one ('use') that differs from other languages in keyword and definition or having one that is similar to other languages ('import') in keyword and has a similar interpretation.

[lydia-duncan]

@bradcray - what about using the "require" keyword, since the dependency implied is very similar?

In terms of the current suggestion - what should "use Foo as M;" imply? Should the symbols of Foo be accessible without any prefix as well as with "M." as a qualifier? If so, is there really much point in renaming the module? If not, is a use statement really appropriate for this operation?

Should the symbols be also accessible via the old name, or should they only be accessible in this context through the shorter name? My preference is for the later, which is consistent with the current renaming strategy, but do others differ?

[bradcray]

I interpreted Paul's suggestion as meaning 'use Foo as M;' causes Foo's symbols to only be accessible via 'M.", not in an unqualified manner, and not via Foo. But maybe I read too much into it.

I'm not sure what you're proposing w.r.t. the 'require' keyword (how it would be used).

[bradcray]

One other thought that occurred to me on the walk in, which is a bit crazy but I'll throw it out there anyway: Last week, there were some discussions of treating code within a 'module M { ... }' context more strictly as compared to code within a top-level ("sketch-oriented") file without a 'module' keyword. If that theme ended up sticking, we could potentially interpret a 'use' in the strict context as being "only nothing / except everything" by default and a 'use' in the loose context as being "only everything / except nothing" by default. This would probably keep current code working while forcing a lockdown of library code.

[lydia-duncan]

(summarizing to be sure I'm thinking about the keyword correctly) The 'require' keyword is currently used to imply that the file named should be compiled at the same time as the source file. Couldn't we make it possible for any module within a Chapel file named to be accessible via explicit naming? Or does the 'require' keyword assume a specific location for the file named? As the creator of this keyword, does that seem like a strong departure from its intended purpose?

The above strategy appeals to me because it feels like a logical extension of the 'require' keyword, avoids an extension of the 'use' keyword that feels like a bit of a stretch, and doesn't introduce an entirely new keyword for the functionality. But I'm not married to the concept - just throwing it out as an alternative idea.

I should note that I'm not in favor of changing the behavior of code that significantly based on whether or not it is in an explicit module declaration - if you're writing a sketch of code that you'll flesh out more extensively as you go, wouldn't you want to know that the behavior you're testing is the behavior it will still have in its polished state?

I do think that Paul's suggestion here is more along the lines of "only access these symbols with the new prefix", but that seems to me like utilizing the 'use' keyword because it's there rather than because what we're intending to accomplish is actually in step with a use of a module (which could arguably be applied to what I'm proposing with the 'require' keyword above - as I said, I was throwing that out there as an option, not saying it is definitely what I think we should do). I think I'd be more in favor of Foo as M; at the top level than use Foo as M;

[cassella]

Eek. All I'd meant was to allow the syntax to create an alternate
name by which the module's symbols could be accessed.

Analogously to use M only foo as bar creating an alternate name for M.foo,

 module Moo {
   var foo = 7;
 }
 use Moo only foo as boo;
 writeln(Moo.foo, " is ", boo);

a user could create a shorter (or for that matter, longer) name
for the module without bringing that module's symbols into its scope
directly,

use Moo as M;
 writeln(Moo.foo, " is ", M.foo);

I hadn't thought of it as conflicting at all with any other "use Moo;"
or restricting it.

But as I said, I don't have a need for it; I just thought it was a
neat use of syntax with a meaning analogous to its existing (err) use.

Alternate syntax for this thing I don't have a need for might include

module M = Moo;

or

ref module M = Moo; // more clearly not a second module

[lydia-duncan]

@cassella, we're thinking we'll merge this PR but won't work on it right away. Would you mind inserting a link to this PR in the .future file so we can refer back to this discussion?

[lydia-duncan]

The changes look good, thanks @cassella!