Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implicit module names #321

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

Ericson2314
Copy link
Contributor

@Ericson2314 Ericson2314 commented Mar 28, 2020

Allow plain module where, inferring the name from context.

Rendered

@Ericson2314 Ericson2314 force-pushed the implicit-module-names branch 2 times, most recently from 28644b8 to 4b8bf1f Compare March 28, 2020 20:43
Endorsements
-------------

.. _`Proposal 316`: https://github.com/ghc-proposals/ghc-proposals/pull/a316
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Link is borked due to stray a.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks1

@nomeata
Copy link
Contributor

nomeata commented Mar 29, 2020

There are use-cases for referring to the current module inside this module; export lists and qualified names.

So can you still do something the equivalent of

module A (module A) where …

or

module A where
tail = undefined
foo = A.tail -- disambguate

with your extension? Do you then again need to “guess” the right module name, or do you envision some way of referring to “the present module” without knowing its name?

@Ericson2314
Copy link
Contributor Author

@nomeata That is a good question. The simplest implementation would allow one to guess the module name, but I think I would rather have a dedicated way to refer the the current module. I haven't thought of a name yet, but I guess that could be a part of this proposal.

@Ericson2314
Copy link
Contributor Author

Ericson2314 commented Mar 30, 2020

What about plain module? Kinda silly, but I think it works:

module (module) where 
module where
tail = undefined
foo = module.tail -- disambguate

@iamrecursion
Copy link

Just a brief thought, here could also work as an identifier for the current module.

module where
tail = undefined
foo = here.tail -- disambguate

@goldfirere
Copy link
Contributor

I don't find the motivation convincing here. I acknowledge the comment at the end of the proposal that aims to be more future-oriented than history-oriented, but still don't see enough of the eventual benefit to warrant yet another extension.

Also: the module name matters, because it is what is used in import statements. It's disappointing that this proposal means that the text of my program is not only a set of strings (the module contents) but now, necessarily, a mapping from strings (file paths) to strings (file contents).

@Ericson2314
Copy link
Contributor Author

@iamrecursion I was hoping to avoid introducing yet another contextual keyword. Also, if the record dot notation passes the . grammar will be far more complex and here.thing will probably be taken.

@goldfirere

Also: the module name matters, because it is what is used in import statements. It's disappointing that this proposal means that the text of my program is not only a set of strings (the module contents) but now, necessarily, a mapping from strings (file paths) to strings (file contents).

I don't like strings or the file system either? I ideally would like to edit the AST of my entire package a thoroughly de-unixed IDE, but as long as modules contain their names that AST is going to be denormalized---I'm too "constructivist" to think of a package as a set of modules whose names happen to not overlap, I really want the map as part of the AST, and ideally nested maps for hierarchical module names.

@Ericson2314
Copy link
Contributor Author

That last bit reminds me, there is also some relation to the local modules / first class modules / structured imports exports proposals. There was some interest in a uniform binding syntax like module <name> = <sub module|import> from @int-index starting in #205 (comment), to make clear that nested modules and qualified imports bind in the same namespace (and also make the combining of qualified imports explicit).

@galenhuntington
Copy link

How about using as?

module as A where
undefined = A.undefined

That could also be useful in named modules:

module My.Long.Module.Name.That.Might.Change as A where
undefined = A.undefined

@Ericson2314
Copy link
Contributor Author

Ericson2314 commented Jun 20, 2020

At first I wasn't excited about module as, but then it came up again completely coincidentally in #270 / #340, so now I'm on board if those go through. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants