{"action":"created","issue":{"url":"https://api.github.com/repos/chapel-lang/chapel/issues/10796","repository_url":"https://api.github.com/repos/chapel-lang/chapel","labels_url":"https://api.github.com/repos/chapel-lang/chapel/issues/10796/labels{/name}","comments_url":"https://api.github.com/repos/chapel-lang/chapel/issues/10796/comments","events_url":"https://api.github.com/repos/chapel-lang/chapel/issues/10796/events","html_url":"https://github.com/chapel-lang/chapel/issues/10796","id":351350240,"node_id":"MDU6SXNzdWUzNTEzNTAyNDA=","number":10796,"title":"Should we be able to extend a module from outside the module?","user":{"login":"lydia-duncan","id":2454710,"node_id":"MDQ6VXNlcjI0NTQ3MTA=","avatar_url":"https://avatars2.githubusercontent.com/u/2454710?v=4","gravatar_id":"","url":"https://api.github.com/users/lydia-duncan","html_url":"https://github.com/lydia-duncan","followers_url":"https://api.github.com/users/lydia-duncan/followers","following_url":"https://api.github.com/users/lydia-duncan/following{/other_user}","gists_url":"https://api.github.com/users/lydia-duncan/gists{/gist_id}","starred_url":"https://api.github.com/users/lydia-duncan/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/lydia-duncan/subscriptions","organizations_url":"https://api.github.com/users/lydia-duncan/orgs","repos_url":"https://api.github.com/users/lydia-duncan/repos","events_url":"https://api.github.com/users/lydia-duncan/events{/privacy}","received_events_url":"https://api.github.com/users/lydia-duncan/received_events","type":"User","site_admin":false},"labels":[{"id":499565193,"node_id":"MDU6TGFiZWw0OTk1NjUxOTM=","url":"https://api.github.com/repos/chapel-lang/chapel/labels/area:%20Language","name":"area: Language","color":"d4c5f9","default":false},{"id":112762321,"node_id":"MDU6TGFiZWwxMTI3NjIzMjE=","url":"https://api.github.com/repos/chapel-lang/chapel/labels/type:%20Design","name":"type: Design","color":"e99695","default":false}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":13,"created_at":"2018-08-16T20:08:08Z","updated_at":"2018-08-28T22:02:38Z","closed_at":null,"author_association":"MEMBER","body":"A quick search wasn't showing me an issue for this, though I know it's been mentioned in passing before by at least @buddha314.\r\n\r\nToday, a module can only contain symbols defined within its braces.  Other languages provide the ability to extend namespaces, but Chapel hasn't typically done so.  Is this something we should provide?\r\n\r\nPotential syntax:\r\nSimilar to how secondary methods can be defined using the type name as a prefix, we could use the module name as a prefix when defining a function.  For instance:\r\n```chapel\r\nmodule M { ... }\r\n\r\nproc M.additionalFunction() { ... }\r\n\r\nmodule M.M2 { ... } // submodule\r\n```\r\n\r\nWe would want to carefully consider the impact of this on private symbols - my thinking is that symbols defined outside the original scope of the module cannot access symbols that are private to the module, unless such private symbols are defined at a similar scope, e.g.\r\n```chapel\r\nprivate proc M.func1() { ... }\r\nproc M.func2() { ... } // can call func1()\r\n```\r\nHowever, that may remove some of the desire for this feature."},"comment":{"url":"https://api.github.com/repos/chapel-lang/chapel/issues/comments/416755653","html_url":"https://github.com/chapel-lang/chapel/issues/10796#issuecomment-416755653","issue_url":"https://api.github.com/repos/chapel-lang/chapel/issues/10796","id":416755653,"node_id":"MDEyOklzc3VlQ29tbWVudDQxNjc1NTY1Mw==","user":{"login":"bradcray","id":7536222,"node_id":"MDQ6VXNlcjc1MzYyMjI=","avatar_url":"https://avatars0.githubusercontent.com/u/7536222?v=4","gravatar_id":"","url":"https://api.github.com/users/bradcray","html_url":"https://github.com/bradcray","followers_url":"https://api.github.com/users/bradcray/followers","following_url":"https://api.github.com/users/bradcray/following{/other_user}","gists_url":"https://api.github.com/users/bradcray/gists{/gist_id}","starred_url":"https://api.github.com/users/bradcray/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/bradcray/subscriptions","organizations_url":"https://api.github.com/users/bradcray/orgs","repos_url":"https://api.github.com/users/bradcray/repos","events_url":"https://api.github.com/users/bradcray/events{/privacy}","received_events_url":"https://api.github.com/users/bradcray/received_events","type":"User","site_admin":false},"created_at":"2018-08-28T22:02:38Z","updated_at":"2018-08-28T22:02:38Z","author_association":"MEMBER","body":"> but I'm already accustomed to writing #include statements in C/C++.\r\n\r\nMe too, so I may share any biases here...  I realize that your questions may be partially rhetorical, but to try and answer them:\r\n\r\n> What gets `include`d?\r\n\r\nThe idea in issue #10909 would be that the `include` would be replaced by the literal text of `B1.chpl`, as with the C pre-processor's `#include` directive.  Thus, the two alternatives you wrote would behave identically.\r\n\r\nIn answering the other questions, I'll be addressing a few potential misunderstandings that I've been mildly worried about (from side conversations) lately:\r\n\r\n> How does the file-level module affect the include statement?\r\n\r\nDon't think of Chapel as \"introducing an automatic module at every file scope.\"  Rather, think of it as \"If a file that's been supplied to the compiler contains top-level code other than comments and `module` declarations, then an implicit file-scope module declaration is introduced to contain that code.\r\n\r\nw.r.t. the interaction with the `include` statement, I'd say that the compiler would never insert an implicit file-scope module for an `include`d file.  Thus, if `A.chpl` had instead said:\r\n\r\n```chapel\r\nmodule A {\r\n}\r\ninclude \"B1.chpl\";\r\n```\r\n\r\nyou'd get a file-scope module named `A` containing a procedure called `getTime()` as well as ann empty sub-module.  I.e., it would be equivalent to:\r\n\r\n```chapel\r\nmodule A {\r\n}\r\nproc getTime() { ... }\r\n```\r\n\r\n> from the global namespace\r\n\r\nYou've used this phrase a few times recently which concerns me that there may be a misunderstanding.  I believe that the only global namespace Chapel has is the one that defines the names of all the top-level modules, and for this reason, I tend not to use the phrase \"global namespace\" w.r.t. Chapel programs (in fact, I try to avoid using \"global\" at all, though not always successfully...).  What do you mean when you use the phrase?  Does it show up in documentation somewhere?\r\n\r\nTo attempt to answer the question, I'm assuming that if `B1.chpl` was named on the compiler command-line, it would introduce a module named `B1` which contained `getTime()` which would be available to any module that `use`d `B1`.  But if the file was only `include`d, then the routine would only be available via the modules in which it was defined."}}
{"actor":{"display_login":"bradcray"}}