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

Allow assignment to globals in other modules #23295

Closed
cstjean opened this issue Aug 17, 2017 · 5 comments
Closed

Allow assignment to globals in other modules #23295

cstjean opened this issue Aug 17, 2017 · 5 comments
Labels

Comments

@cstjean
Copy link
Contributor

cstjean commented Aug 17, 2017

Currently, SomeModule.variable = 5 yields cannot assign variables in other modules. I get that globals aren't recommended in general, but they are occasionally convenient for specifying things like verbosity level, or the color of the output. Could we allow them, when qualified with the module? The alternatives (Ref/accessors) are a bit verbose.

@vtjnash
Copy link
Sponsor Member

vtjnash commented Aug 17, 2017

verbosity level, or the color of the output

These should be specified using an IOContext

The alternatives

The primary recommended alternative (which is missing from your list) is to eschew globals in favor of using locally scoped constructs (aka local variables / arguments)

But since there's already a number of ways to do this, (notably @eval, although also accessors), I could be convinced either way.

@StefanKarpinski
Copy link
Sponsor Member

This can always be allowed later, so I would not be in a hurry to do this.

@cstjean
Copy link
Contributor Author

cstjean commented Sep 1, 2017

These should be specified using an IOContext

TIL, thank you. AFAICT, there is no way to permanently specify a value (eg. the color of some object's pretty-printing) when it would be tiring and redundant to specify it to print each object in the REPL. (#20509)

If I have a deeply-nested warn("Low accuracy in foo() computation") warning in my package, and I want to offer a way to disable it, is there a recommended non-global way to do that without passing a warn_on_foo_accuracy keyword argument throughout my codebase?

Common Lisp has the following built-in global variables, in addition to vendor-specific extensions:

*break-on-signals* *compile-file-pathname* *compile-file-truename* *compile-print* 
*compile-verbose* *debug-io* *debugger-hook* *default-pathname-defaults* *error-output*
*features* *gensym-counter* *load-pathname* *load-print* *load-truename* *load-verbose* 
*macroexpand-hook* *modules* *package* *print-array* *print-base* *print-case* *print-circle* 
*print-escape* *print-gensym* *print-length* *print-level* *print-lines* *print-miser-width*
*print-pprint-dispatch* *print-pretty* *print-radix* *print-readably* *print-right-margin* 
*query-io* *random-state* *read-base* *read-default-float-format* *read-eval* *read-suppress*
*readtable* *standard-input* *standard-output* *terminal-io* *trace-output*

I can get, set, or temporarily change (dynamic scope) each of these with setf and let. It's a really clean, simple interface. I understand that Julia has type-stability concerns that preclude doing the same in Base, but it would be nice to have globals for performance-insensitive "customization" of my packages.

@cstjean
Copy link
Contributor Author

cstjean commented Sep 1, 2017

On second thought, if #20509 is implemented, that would cover most of my use cases.

@cstjean
Copy link
Contributor Author

cstjean commented Aug 4, 2022

Fixed by #44137, AFAICT.

@cstjean cstjean closed this as completed Aug 4, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants