Add support for a behaviorspace-experiment-name primitive

[TheBizzle]

From @alan-isaac:

Wouldn't it be nice for NetLogo to provide access to the name of the currently running BehaviorSpace experiment (not just the run number)?

This doesn't look very difficult to implement. AbstractWorkspace._behaviorSpaceRunNumber current holds the run number. I gets initialized by org.nlogo.lab.gui.Supervisor, which has a protocol member that happens to hold the name of the BehaviorSpace run.

One solution would just be to add another variable to AbstractWorkspace and store the name in there. Another might be to create some small container class BehaviorSpace settings that lives outside of the org.nlogo.lab package, and then store one of those in AbstractWorkspace for the BehaviorSpace primitives to grab their values out of.

[TheBizzle]

I reassigned this ticket to 5.2—mostly as a suggestion. I think it should really go out in the next release, and the proposed primitive doesn't seem difficult to implement (as I described above). The issue has been languishing here for several months, and it solves a problem that users can't really work around by themselves.

[frankduncan]

I don't think it's going to get in this release. I'll keep it in 5.x for the time being and revisit later.

[frankduncan]

I'm defaulting this to the empty string unless there's a reason to do null

[TheBizzle]

Empty string makes sense to me. Might also make sense to forbid the Behavior Space GUI forbid the creation of an experiment if the experiment's name is empty. Currently, empty string names are allowed.

[frankduncan]

I don't think disabling that is necessary. No harm done.

[SethTisue]

I think empty string is fine. At one time I would have been strongly tempted to return false, but these days, I'm more inclined to make decisions that are compatible with static typing, even static typing that our language doesn't actually have.

[SethTisue]

One other possibility would be to add a behaviorspace? primitive, and then have behaviorspace-experiment-name and behaviorspace-run-number signal runtime errors if you don't check the boolean first and BehaviorSpace isn't running. For something closer to the language core and likely to affect model correctness, that would be the most NetLogo-ish approach, IMO. For this, it's hard to get too worked up about it one way or the other.

[frankduncan]

Especially since that level of revamping is not something I'm going to be able to accomplish by next friday.

For a long term solution, would it be better for behaviorspace to be a plugin/extension pair?

[SethTisue]

Absolutely.

(But as usual, see the discussion in #574 about what that implies, exactly. I know you know already, but I'm including the link for the benefit of anyone else reading these comments.)