0_t

32:T48a,## Technical remarks on output Look at the recursiveness in this specific example: in Javascript, this looks awful! I think this example needs memoisation just to project y at time period 20 (think about the exponential rise in redundancy! memoisation is a bare minimum requirement). Even still I think its bad execution. However, the code is also simple: its not hard to imagine a straightforward conversion to a system with better treatment of recursion, like Haskell. Or a more complicated and delicate conversion to loops. Imo the output code reflects closely a spreadsheet: dependencies on previous cells. Conversion to spreadsheet is also feasible (if that does much!) or using a similar execution model, as is some fancy runtime basing itself on such execution models. I amn't spending time on a solution here for now: I do memoisation where I can, have memo-loader as a high priority, and for now I'm trying to use calculang within these limited bounds that I'll get to grips with over time. So this is an important area where other input/effort would be seriously valued. (I do know its huge, but I just can't give it the attention it deserves now)33:T41a,## Perspectives: vs a spreadsheet calculang looks hard: it's code, I worked to minimize boilerplate but I didn't eliminate it e.g. look at `y({t_in:t()-1})`. It's a weird recursive style of programming that is a debatable approach to "a language for calculations". The approach looks unfamiliar. But lets look again. Here is how I might model the final model above in a spreadsheet: ![2021-12-18 (2).png](${await FileAttachment("2021-12-18 (2).png").url()}) (I could of course use a hardcode/inconsistent formula for y and hardcode the 100 at t=0 which simplifies the formula highlighted) This to me looks structurally the same as the calculang code (including in recursion sense), but using **rigid references tied to layout** instead of **references tied to meaning** and that scales according to applied usecase. calculang **is** code and may be harder than spreadsheets to approach now: but I don't see a significant impediment to being **more** intuitive than spreadsheets for something non-trivial in the long-run. (with good UI effort)34:T1451,html` `35:[{"id":"d35527579e6261000d3adfefdbb16ad7010c71b05a09e840e6fbd29916be4fff8b4a926693457e068314e584b7962cff94bda22ceecf152b1e97c86aa45d1fc7","href":"https://static.observableusercontent.com/files/d35527579e6261000d3adfefdbb16ad7010c71b05a09e840e6fbd29916be4fff8b4a926693457e068314e584b7962cff94bda22ceecf152b1e97c86aa45d1fc7","name":"image.png","type":"image/png","lastModified":1639517924707.899,"size":96432},{"id":"c9ca599ba3d7c880d8b0399cd8b57b0411ae82beb2656121eaa63b4279955c17a61be43cc4132d31de8f60f661a892d2dcbe2e1f5c67f40c9f56d78e2a2a5e24","href":"https://static.observableusercontent.com/files/c9ca599ba3d7c880d8b0399cd8b57b0411ae82beb2656121eaa63b4279955c17a61be43cc4132d31de8f60f661a892d2dcbe2e1f5c67f40c9f56d78e2a2a5e24","name":"2021-12-18 (2).png","type":"image/png","lastModified":1639863959172.653,"size":7313}] 2f:{"title":"calculang compilation, examples (wip)","cells":[{"id":18,"value":"# calculang compilation, examples (wip)\n\nI can make this much more accessible by focusing on [issue #34](https://github.com/calculang/calculang/issues/34) (more or less done but...) and also integrating in a simple way into a VSCode extension (see below).","pinned":false,"hidden":false,"mode":"md"},{"id":44,"value":"viewof outputFormat = Inputs.radio([\"side-by-side\", \"line-by-line\"], {label: \"diff format\", value: 'side-by-side'})","pinned":false,"hidden":false,"mode":"ojs"},{"id":0,"value":"### LHS = calculang, RHS = compiler transformation","pinned":false,"hidden":false,"mode":"md"},{"id":7,"value":"diff(`export const t = () => t_in; // explicit input\n\nexport const y = () => (t() == 0 ? 100 : y({ t_in: t() - 1 }) - vy());\nexport const vy = () => 5; // linear fall`,\n`export const t = ({ t_in }) => t_in; // explicit input\n\nexport const y = ({ t_in }) => t({ t_in }) == 0 ? 100 : y({ t_in: t({ t_in }) - 1 }) - vy({});\nexport const vy = ({}) => 5; // linear fall`, {outputFormat } )","pinned":false,"hidden":false,"mode":"ojs"},{"id":54,"value":"Notice the boilerplate which is managed by calculang (via graph, example below)\n\nFollowing diff is changes to the calculang code, to model gravity (without a specific value: instead an additional input):","pinned":false,"hidden":false,"mode":"md"},{"id":32,"value":"diff(`export const t = () => t_in; // explicit input\n\nexport const y = () => (t() == 0 ? 100 : y({ t_in: t() - 1 }) - vy());\nexport const vy = () => 5; // linear fall\n`,`export const t = () => t_in; // explicit input\nexport const g = () => g_in; // explicit input: gravity\n\nexport const y = () => (t() == 0 ? 100 : y({ t_in: t() - 1 }) - vy());\nexport const vy = () => g() * t(); // gravity, no air resistance\n`, {outputFormat } )","pinned":false,"hidden":false,"mode":"ojs"},{"id":58,"value":"impact on compilation (now y depends on g as well as t: this is determined from the relationships in the graph (vized below)):","pinned":false,"hidden":false,"mode":"md"},{"id":36,"value":"diff(`export const t = () => t_in; // explicit input\nexport const g = () => g_in; // explicit input: gravity\n\nexport const y = () => (t() == 0 ? 100 : y({ t_in: t() - 1 }) - vy());\nexport const vy = () => g() * t(); // gravity, no air resistance\n`,`export const t = ({ t_in }) => t_in; // explicit input\nexport const g = ({ g_in }) => g_in; // explicit input: gravity\n\nexport const y = ({ t_in, g_in }) => t({ t_in }) == 0 ? 100 : y({ g_in, t_in: t({ t_in }) - 1 \n}) - vy({ g_in, t_in });\nexport const vy = ({ g_in, t_in }) => g({ g_in }) * t({ t_in }); // gravity, no air resistance`, {outputFormat } )","pinned":false,"hidden":false,"mode":"ojs"},{"id":63,"value":"Of course, this specific development necessitates updates to applications. This is because g is modelled as an input with no constraint anywhere. But note that application-specific constraints are possible.\n\nNow, imagine a further development for air resistance: from a calculang perspective this is only about developing the relevant impact on vy, and it will flow appropriately to dependents without individual updates or allowance.\n\nThe main motivation behind the compilation is about minimising boilerplate and maximising reusability.\n\nThe above example doesn't demo modularity or overriding functions (/\"application-specific constraints\"), I will do this in another example!","pinned":false,"hidden":false,"mode":"md"},{"id":116,"value":"$32","pinned":false,"hidden":false,"mode":"md"},{"id":124,"value":"$33","pinned":false,"hidden":false,"mode":"md"},{"id":86,"value":"## dependency tree used in compilation (last compile above with g)","pinned":false,"hidden":false,"mode":"md"},{"id":73,"value":"$34","pinned":false,"hidden":false,"mode":"ojs"},{"id":76,"value":"nodes are: `_: []`\ninput links are the input convention logic. They have a +impact on the dependency flow of inputs.\n\ncall links are function calls, some calls have 'negs' e.g y({t_in:t()-1}) which MAY have a -impact on dependency flow of inputs (the only neg below doesn't: t_in remains an input in 0_y because of the dependency which remains via 0_vy <- 0_t)\n\nThe neg logic is the 'hardest' piece of logic and I probably don't help myself with the bad terminology!","pinned":false,"hidden":false,"mode":"md"},{"id":103,"value":"## vscode\n\nwhat above looks like in vscode (output comes out auto, but compare output/input is manual). This can be much more concise, see [comments](https://github.com/calculang/calculang/issues/34#issuecomment-993776897)\n![image.png](${await FileAttachment(\"image.png\").url()})","pinned":false,"hidden":false,"mode":"md"},{"id":3,"value":"import {diff} from \"@jobleonard/diff-tool\"\n","pinned":false,"hidden":false,"mode":"ojs"}],"files":"$W35","stdlib":"1","titling":"auto"}