Variable Generation Overhaul

[carsonwoods]

Right now variables are being generated on a per case basis. This means that when we need to make a change to how variables are generated we have to do this on every sampler. This should be outsourced to a single "factory" function that will produce all variables in a uniform way.

[martinruefenacht]

There is a problem with this. The Samplers are intended to sample the function, ie generate different argument lists. For that we need to be able to control how we generate the variable and also if we want to generate a variable correctly for negative testing.

[martinruefenacht]

I think it would make sense that a Sampler has the methods generate_function_samples and generate_variable_samples. The Sampler is defined by the behaviour of sampling and what it samples is actually irrelevant.

[martinruefenacht]

"out" arguments should probably just be generated in the FunctionSample class in the first place. They are always the same and do not serve testing purposes therefore a Sampler is not required. It is essentially a return variable.

The "out" variables (return, etc) are there as a mechanism to capture output in the lemonspotter runtime.

[martinruefenacht]

IN and INOUT parameters need to be generated in Smaplers, but OUT parameters can be generated in FunctionSample.

[martinruefenacht]

This involves the change commented as a TODO in valid.py. Moving partition sampling to the Partition class/creating multiple Partition subclasses, instead of a improvised RTTI.

[martinruefenacht]

41 fixes this problem, out arguments are generated in FunctionSample. For the moment that is good enough I think. For the in/inout argument we need to do this in the Samplers, because only they know how they want to do that.