Implicit typing for variables

[PTraeder]

I am currently working on a change that would make function declarations not require a type.

E.g. something like

a mS
b mS
function foo = a + b

would assume (and install) the type of mS for the (alias) function foo.

Here is where I need your input:
Since these function declarations are grammatically the same as regular variable declarations (i.e. defined by the same rule) it would be rather straightforward to install the same changes for regular variables.

However, at that point it becomes no longer possible to discern between a declaration and an assignment in the update block where both can occur:

state:
    a mS
    b mS 
end

...

update:
    c = a + b #this is parsed as an assignment, when it should be a declaration
end

One easy solution for this would be to change the syntax for declarations to expect := instead of a simple =

Since @heplesser has in the past inquired about making types optional for varialbes, I judged this to be a good time to get everyones feedback on this.

@DimitriPlotnikov @jougs @Silmathoron

[Silmathoron]

Wouldn't it be possible to simply consider as declaration any left member where a variable name appears for the first time?
Otherwise I have no particular problem with the use of := for declaration, but this would be a breaking change in user api, so I guess this would depend on the policy that @heplesser and @DimitriPlotnikov want to follow (and of the current number of users)

[PTraeder]

@Silmathoron
While I dont see how that would be impossible, it would mean rearranging the AST as provided by the parser, since this is a grammar problem. I do this on other occasions. In this case it would be during symbol table creation, and a bit overkillish compared to the simple grammar change I proposed.
(Unless there is some grammar magic to be worked here. But I have little knowledge about MC/Antlr)

I have to note again:
This would not be a problem if I would not extend the solution from function declarations to all variables. The function keyword in the corresponding rule would be enough to distinguish bewteen declarations and assignments.

[DimitriPlotnikov]

@PTraeder
Could you, please, write your short feedback, that we should do it and I'll close the issue?.

[DimitriPlotnikov]

:= would be fine.

[heplesser]

First a question to ensure that I understand everything correctly:

• function f = a + b defines f as an alias for a+b, so that wherever f appears, it would be replaced by a+b and upon evaluation use the values of a and b that a current at the moment of evaluation
• c = a + b is permitted only in an update section, in this update section---and only there---operations have a temporal order, and here the expression on the right hand side is evaluated and the resulting value assigned to c. Later changes to a and b do not affect the value of c

Is this correct? Then, I think, it would make sense to use := for the latter case independent of what we do about units. One might then even wonder if one needs the function keyword.

Concerning units, the question is what to do if units in an expression either do not match perfectly or are combined multiplicatively forming new units. Some examples:

• Let a pA and b nA: which of the two would be choose as unit of f = a + b?
• Let g nS and V mV: then neurosciencist would expect that the current g * V has units pA---can we infer this automatically?

I assume that people elsewhere have worked on inference of units, but I don't know that literature.

[jougs]

I agree with @heplesser's assessment that the function keyword is actually not be needed if we use := for the assignment of what we earlier called an alias.

Regarding the question of units, I think this should be possible by always using the natural neuroscientific unit (ms, mV, nS, pA, GOhm) if things become unclear with respect to the magnitude.

[DimitriPlotnikov]

We decided to postpone the support of this due to more complex implementation of the language background. The effort for implementing it is currently not justified (since we are moving to PyNESTML)