About GLOBAL variable promotion to RANGE (instead of thread) about nrn HOT 2 CLOSED

It is certainly possible though tedious to either change the implementation from "promote to
thread variable" to "promote to range variable". We have been asking the user to manually replace
GLOBAL with RANGE (and. comment out TABLE statements). With regard to TABLE, I should have
been more precise in saying that TABLE statements that DEPEND on RANGE variables would not
work (There is only one global table per TABLE statement and it is entirely updated if what it depends
on changes. The table functions are, or can be easily made, thread safe so that the table values
copied to RANGE minf, etc would not suffer from race conditions.

However I don't like how the situation has evolved in regard to volatile variables (e.g. minf) being
used for serial, pthread, massive simd architectures. The original use of GLOBAL minf for
single thread computations was not at all descriptive but just a trick that depended
on knowing how it would
be translated into c and therefore could be repurposed in order to save memory. Much better would
have been to allow FUNCTION to return a tuple a la Python. It would not be hard to add this
feature.... return (minf, hinf, ninf, mtau, htau, ntau)
and have
(minf, hinf, ninf, mtau, htau, ntau) = rates(v)
On the other hand, (to avoid changes at the user level) the semantics of GLOBAL foo,
when foo is written to in a PROCEDURE and only used in a block after the procedure is called,
could generate appropriate c code so that they
are treated as local variables. (with provision that thread 0 copies also to the GLOBAL
foo)

I don't believe there is any serious difficulty in making TABLE work in the CoreNEURON context.

from nrn.

MOD file compatibility will be now handled by NMODL. See : BlueBrain/nmodl#230. So this is good to close.

cc: @iomaganaris

from nrn.