Jason has solved the half of the problem I neglected! If you combine his `clear-most` with my solution, you should end up with an all-purpose workaround.
On Fri, Oct 17, 2014 at 5:36 PM, Jason Bertsche < [email protected]> wrote: > Alan, > > I think we agree that there's a flaw here, and I can assure you that we, > the developers, *are* thinking about solutions to this. Would it solve > your problem to be able to optionally specify a default value for globals > that is restored whenever `clear-globals` (or, by extension, `clear-all`) > is called? For example, you could specify `globals [my-global = 3]` to > initialize `my-global` to `3`. Personally, I think this is a pretty > sensible solution to something that has *always* irked me about NetLogo. > > On the "null" side of things, I have a fairly strong aversion towards > adding a special invalid value to the language (like Java's `null` or > JavaScript's `undefined`), since I think it's become pretty apparent in the > programming community at large that such special invalid values in a > language are a net negative for writers of code in the language and for the > developers of its libraries alike. I don't feel that the NetLogo solution > of defaulting values to `0` is any better—arguably worse, really—but > *adding* a value to the language for doing something that leads the > error-prone paranoia of continually checking variables to make sure that > they aren't *that one evil value* simply seems like a step backwards to > me. > > As for workarounds, it sounds to me like you just don't want globals to be > reset between your BehaviorSpace runs. If that's the case, you could > substitute any calls to `clear-all` for calls to some procedure > `clear-most`, where the code for that is: > > ``` > to clear-most > clear-ticks clear-turtles clear-patches clear-drawing clear-all-plots > clear-output ; or whichever of these are relevant to your model > end > ``` > > Afterall, `clear-all` simply runs all of that code, plus `clear-globals`. > Yeah, it's not pretty—it's actually comedically long code—but... it's a > workaround. > > > On Friday, October 17, 2014 4:19:54 PM UTC-5, Alan Isaac wrote: >> >> There is no good workaround. The developers have not suggested a >> workaround. This is a widely recognized problem. I personally do not see >> how it will be adequately addressed unless initialization of non-interface >> globals is changed. I would love to hear how the developers are thinking >> about this problem, which poses very real problems for serious NetLogo >> users. >> >> My recommendation would be to plan a transition. Immediately, introduce >> a new keyword for the declarations section, allowing specification of the >> default value for non-interface globals. (E.g., `__global-default`.) >> Ideally, this would immediately be supported by the introduction of a new >> value (e.g., `undefined`). Users who want this functionality now would be >> able to include the declaration >> >> __global-default undefined >> >> In a future version, this would become the default behavior. >> >> I plead that the developers take this design flaw seriously and that it >> not be passed on to Tortoise! >> >> Alan >> >> -- > You received this message because you are subscribed to the Google Groups > "netlogo-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "netlogo-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
