Add some example mechanisms to language proposal #6
Conversation
Just the first more or less complete draft!
* Add omitted characters from _other-new-line_. * Consistently refer to non-type, non-unit expressions as 'value expressions'. * Add link to survey article on chemical reaction network theory where reaction syntax in records is discussed. * Add small example of ambiguous expression parsing leading to same semantic interpretation. * Define what is meant by an 'outer expression'. * Clarify that a _case-expr_ must have a final branch of the form `| otherwise → ...`. * Replace errant `constant` keywords with `def`. * Split when definitions into when-clauses (testing a predicate), and on-clauses (matching an event). Add an additional optional predicate to an on-clause. * Clarify that in `initial evolve for _t_ from`, _t_ must have type `time`. * Revert regime transition syntax in when-clauses and on-clauses to `regime R` from `regime = R;` on the grounds it really isn't anything like a binding. * Change when- and on-clause semantics in regimes, so that over of applicability is clear, and so that any delivered event can trigger at most one on-clause. * Clarify the points in the syntax rules where the interface extension points lie. * Fix miscellaneous small errors, bad internal links.
* Fix ytpos, thinkos. * Add on-defn to region-decls. * Use 'regime X' not 'regime = X;` syntax in example. * State that when predicates are general (i.e. need not be predicates involving just the mechanism state.)
| export parameter gamma = 0.05; # Proportion of unbuffered calcium. | ||
| export parameter decay = 80 ms; # Calcium removal time constant. | ||
| export parameter minCai = 1e-4 mM; | ||
| export parameter depth = 0.1 µm; # Depth of shell. |
There was a problem hiding this comment.
Thoughts on export parameter, after seeing it used in anger
- That's a lot of typing to little effect, maybe using a block like
is bit cleaner to read/write
export parameters { gamma = ...; ... } - Metadata/docstrings could be helpful to the user, like we discussed on model in general. Something that could be presented in a REPL or GUI
- For tweakable parameters we might want to allow bounds/ranges
There was a problem hiding this comment.
On the block syntax for multiple exports, I do see your point, but I was hoping to keeping the language less structured.
What is in the proposal so far is a bit verbose, but each part of the syntax does have a function, and it does have the advantage of being consistent with other existing interface syntax, and of making the distinctions clear between e.g.
parameter gamma = 1; # define a parameter
export gamma # export a defined parameter
export gamma as γ # export a defined parameter under a different name
export parameter gamma = 1; # define and export a parameter
Mentioned the parameter annotation in #arblang chat; I think it's a good idea — we just need to find a good syntax.
On bounds, my preferred solution would be to use the interval types proposed as an extension, as then the type is the range in question, which can then be used both in UI, in solution generation, and in type checking.
| bind flux = molar flux "ca"; | ||
| bind cai = internal concentration "ca"; | ||
| effect molar flux rate "ca" = -gamma*flux - (cai - minCai)/decay; | ||
| } |
There was a problem hiding this comment.
Question: Could I do this? If not maybe it should be allowed
let ion = "ca";
bind flux = molar flux ion;
bind cai = internal concentration ion;
effect molar flux rate ion = -gamma*flux - (cai - minCai)/decay;
seems like good practice.
There was a problem hiding this comment.
If we did something like this, I'd want not to use e.g. let to do it, just because we then start having to treat string literals more seriously in the language.
On the other hand, I expect we will allow rebindings of ions as we do currently in Arbor, so that "ca" above can be thought of as being as generic as ion might be. If someone wanted to make a generic mechanism over an ion, they could for example just consistently use "x".
| w_plastic = S.w_platic + S.apost; | ||
| }; | ||
|
|
||
| on δt = post; state = { |
There was a problem hiding this comment.
Looking at this, I find a bit confusing. The on statement is only connected visually to its effect.
Imagine this:
on ...
<1000 lines of comments snipped>
state = ...
I know, do not do this if it hurts, but we should strive to make bad patterns hard to use.
There was a problem hiding this comment.
With our current syntax, you can do the huge interstitial comment thing in any expression, so I'm inclined to say that this really is a case of "well just don't do that".
halfflat
force-pushed
the
lang-proposal-examples
branch
from
04a9c59 to
9ad09d8
Compare
None of the examples cover regimes yet, but do try and exercise some of the syntax variants and Unicode alternatives.