<Property> , <Parameter>

[borismarin]

I am slightly confused by the usage of <Parameter> and <Property> given our discussions on "mutable parameters" (#32). Currently, it seems that <Parameter>s are only supposed to be set at <Component> creation time, whilst <Property>ies can be overridden with <Assign> under <Structure>. @robertcannon , how does that fit within our inheritance/overriding discussion? Didn't we say something about changing how <Structure> is handled?

In other words, how should an user specify that each one of the components in a population has a different value for one of its Parameters/Properties (or that all of them have the same value for the Parameter/Property except for one)?

There's <Constant> as well, which seems to allow <DerivedParameter>-like constructs. Would <DerivedParameter immutable="true"> make sense? (I am not convinced, just like in the <Child(ren)> case, just curious).

[robertcannon]

At one stage, Parameters were immutable and Propertys (not sure what others do, but I tend just to regularize english grammar rules for plurals ad the like in source code) were the way to define something that varies from instance to instance.

A Property was then something that should exist on an instance of the model, but that couldn't be defined at the component definition level (ie, you couldn't set a default value). One use case is if you are defining a cell which will be placed on a grid. You can say it will have a Property x and a Property y that must be set when the grid is built. But these aren't parameters of the cell model in the way that the reversal potential is, say.

Once you have mutable Paramters, you could instead define a couple of normal Parameters called x and y and change them on a per-instance basis.

So, is there really a difference between a Property and a mutable Parameter? In the example above, there is the distinction that if you take a cell in isolation, then its behavior doesn't depend on any of its Propertys, but does depend on its Parameters. That is, the Propertys are only used when more than one cell is involved, as in establishing distance-dependent connections. I'm not certain that this is a general rule, but I think it might be:

• Propertys can't figure in expressions inside the Dynamics element whereas Parameters can.
• Propertys can't be set in a component definition,only by assignment from the structure.

On the other hand, I can't see any reason for the structure being able to do things to Propertys that it can't do to Parameters.

I think DerivedParameter immutable="true" does make sense, or even, get rid of DerivedParameter and just have:
Parameter immutable="true" if you don't want to allow it to be changed on a per-instance basis
Parameter value="an expression..." instead of DerivedParameter

Then a Constant just becomes Parameter value="expresion...." immutable="true"

What do you think?

[borismarin]

Well, most of my comments are "exploratory" [and, more importantly, a way of publicising design decisions so that the future generations will benefit from your experience ;) ]. This last round of issues mostly had to do with "decreasing the entropy" of the language, or having less ways of expressing the same concept. As the Lems "benevolent dictator for life", I guess that you should have the final word on those changes - imo the worst thing that can happen now is having diverging flavours of Lems just because someone (me) has been picking on (Derived)Parameters...

That being said, I like the idea of getting rid of both <Constant> and <DerivedParameter> in favour of <Parameter value="[expression | literal]" immutable="[true | false]">. Less classes, less code, less documentation to write, less potential users frustrated by the amount of similar constructs.

[borismarin]

With respect to <Property>s / <Parameter>s, doesn't

there is the distinction that if you take a cell in isolation, then its behavior doesn't depend on any of its Propertys, but does depend on its Parameters.

mean that it is a property (or even better, a parameter, haha) of the "population" instead of the cell? If you want to reuse the cell as a building block in other simulation, does it need to carry this kind of information with it?

[robertcannon]

It's very useful - this is the first thorough review of the Lems elements we have had.

Re your question, perhaps it does mean it belongs to the population not the cell. The cell doesn't need to carry it with it if it is reused so it shouldn't be a Parameter.

The way I usually approach these things is to imagine how you might describe it in plain text. "There is a population, A, of cells each governed by [equation] where V-rev = ... (anything in a 'where' clause should almost always be a parameter). The cells are placed on a grid with coordinates (x_i, y_i) for i=1,...n and connected according to the distance between them with probability p = f(x, y)"

Alternatively, you could say:
"Each cell has a position, x, y, where x_i = f(i), y_i = g(i), i = 1, n."

"has..." tends to suggest a parameter but with less confidence. The first version definitely suggests the x,y pairs are a property of the population with a mapping between them and the cells rather than properties of the cells (this is OK in Lems: you can create an array of points with x and y, and then use CoInstantiate to associate a cell with each one). The second tends towards the "Property" concept. You wouldn't say "where x =..." since the x hasn't been used in an expression for the cell. It is only used in an expression for the connectivity which is a population property. So, this favours adding indexed arrays as population properties somehow in preferences to a Property element on the cells.
We could do with a few more use cases to work out what is the best partition of information.