I am rewriting an application in Mathematica. The previous version used global variables, which I find distasteful, but to avoid it I am needing to pass several static Datasets and Associations around a lot. What is the recommended practice here?

I import several files from CSV into Datasets. They aren't particularly large, but they are used for a lot of the processing. This is a sustainability-oriented business simulation game, played at live events by 100+ people.

There is immutable data in the form of datasets for market forces, investment, and available innovations. There are also mutable constructs, primarily in the form of KPI data that we use to measure progress.

All of these interact, so I end up with a lot of functions like: processInvestments[marketForceData,investmentData[#1],kpiData,innovationData]&/@teamNames

that call other functions that require that data as well. Several of these tables vary based on number of teams or other factors as well. One thing I've thought about doing is using a function in the local variable definition of Module to generate them separately as locals, as least for the immutables:


I'd love an RTFM if that's around.


  • $\begingroup$ Can you be more specific? A small example usually goes a long way here. $\endgroup$
    – Yves Klett
    Dec 14 '16 at 5:29
  • $\begingroup$ added some details. Thanks for asking, happy to add further clarification or examples if it would help. $\endgroup$
    – Rick R
    Dec 14 '16 at 8:04
  • 2
    $\begingroup$ Why do you find global variables distasteful? For immutable data shared between many functions this seems like an entirely acceptable approach. $\endgroup$
    – Mr.Wizard
    Dec 14 '16 at 9:23
  • 1
    $\begingroup$ Possibly related: mathematica.stackexchange.com/q/55833/121 $\endgroup$
    – Mr.Wizard
    Dec 14 '16 at 9:24
  • $\begingroup$ Probably three reasons, none of which may be too compelling. First, globals make me feel uncomfortable with values in my tests, I feel more comfortable with the values explicitly defined. Second, the previous version of the code relied heavily on globals, and I'm probably reacting strongly in the opposite. Third, there are many mantras to avoid globals. There are also many mantras to avoid mantras :) $\endgroup$
    – Rick R
    Dec 14 '16 at 16:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.