Theoretically we have global variables and functions. You can declare a public class with static members and those should be accessible by all subsequent code. For example:
public class The { static int number;
// a bug forces one to declare static objects as references static Event @ event; }
Static variables in public classes work for sharing data. But perhaps there is a more elegant way to do this. If you want to share just a bit of data between future shreds, one must use two of lines syntax minimally, but it's big on words and punctuation and short on meaning: public class Foo { static int bar; } 4 => Foo.bar; If I define a class in a shred file and make changes, the VM doesn't allow you to redefine the class (so you must remove it from your buffer). This is a temporary practical problem. Also, it semantically implies there is some class of objects called Foo, and bar is a piece of data that relates to all of them. We aren't really sharing data between instances of Foo, we're sharing data among shreds. We are only using classes for this because it allows us to hijack a global namespace in the VM (the namespace of classes) for sharing data. We could also do this by having a machine-wide dictionary: machine.set( "beatEvent", new Event ); //this has typing issues or perhaps like this: 3 => glob int bar; //this has a bad reputation Globals have a bad reputation for cluttering programs. But in this case using class data isn't much better, and requires more meaningless syntax. Of course, static class data does have some things going for it. Overall, the syntax of ChucK is very minimal, and it conforms to the expectation of standard languages (mostly C++ and Java). This makes it easier to learn and understand, and it might make it more timeless. For a java programmer, storing global data in class (static) variables provides minimal surprise. Arguably, live-coding environments are subject more pressure than systems and applications languages to be clear and to be terse. best, Graham