Chapel Users / Devs —
Some of you may remember the conversation below from a few years back
about introducing "local static" variables in Chapel. It's come up again
in a GitHub issue with some new arguments for its value / convenience, so
I wanted to give those of you who shot it down last time a heads-up in
case you still feel strongly opposed to it and wanted to weigh in:
https://github.com/chapel-lang/chapel/issues/12281
-Brad
On Thu, 14 Jul 2016, David G. Wonnacott wrote:
Since you have module variables, what is the case for introducing
static-to-function? To make something even more local than a module
variable? Why not just suggest a submodule ... can Chapel have a module in
a module? I'm not sure, but that seems to me to be a more elegant solution
than adding a keyword for more-local-than-a-module names. To give a
coherent suggestion, I'd want to know *why* this exists in a modern
language in the first place. C/C++ need it for compatibility, and the
community is somewhat trained to use it, but I don't see a good case *for* it
in a language with a good module/namespace system, other than to make
concise something that shouldn't be happening that often.
Dave W
On Thu, Jul 14, 2016 at 2:02 PM, Mike LeVeille <[email protected]> wrote:
Haha I'll second: eliminating global/module variables (constants could
stay).
I'd also vote against adding "static", since it seems like a jury rig. If
a developer is considering using "static", the function should probably be
moved to a class (or add a parameter to the function instead).
On Jul 14, 2016 12:32 PM, "Brad Chamberlain" <[email protected]> wrote:
A similar discussion to this is going on in Facebook-land (no Facebook
account should be required to read it, I believe):
https://www.facebook.com/ChapelLanguage/posts/1761242420787583
The gist of it is me saying "This is morally not really different than
permitting functions to have read/write access to module-scope variables"
and Russel Winder saying "Yeah, you should get rid of that as well."
I'm not convinced the community would go for that change, but since it's
come up, I guess it's worth asking... Opinions?
-Brad
On Thu, 14 Jul 2016, Jason Riedy wrote:
And Brad Chamberlain writes:
Please send any proposed keywords to me, optionally with a short
rationale. In a few days, I'll send out a summary of responses
received
(including our own brainstorming, which I don't want to influence you
with
at the outset).
Possibilities:
- hidden_state
- beware
- bugs_hide_here
- youll_regret_this
- later_developers_will_curse_your_name
Are you sure this is needed?
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and
traffic
patterns at an interface-level. Reveals which users, apps, and
protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning
reports.http://sdm.link/zohodev2dev
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and
traffic
patterns at an interface-level. Reveals which users, apps, and protocols
are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning
reports.http://sdm.link/zohodev2dev
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and
traffic
patterns at an interface-level. Reveals which users, apps, and protocols
are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning
reports.http://sdm.link/zohodev2dev
_______________________________________________
Chapel-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-users
_______________________________________________
Chapel-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-users
