Higher-order macros about firmware

[kareltucek]

Hi Andrew and thanks for getting in touch!

I have considered a possibility of adding a command which would allow executing macros as functions. Unfortunately, the matter is rather complex - call stack would have to be implemented so that you could return from a call, and some sort of typing system which would allow passing arguments... Also one of the complications is that the amount of available RAM of UHK is rather limited, while modules are not-yet implemented and official tracker promises some features which will eat significant amount of memory in the future. ...And the macro-state records are currently quite large. As a result, I don't feel very strongly about implementing such thing - It is not impossible, but so far, it wasn't worth the trouble for me.

One thing I could implement quite easily is an "exec" command, which would execute another macro in place of current macro - i.e., with no possibility of returning to the caller macro. How much would such functionality help you?

Also, could you explain some real-life examples? There might be some other solution not requiring a full-fledged call stack.

[luteijn]

Might consider an 'include X' instead of a 'call X' command that would inline the X macro in the flash. The hard part would be how/when to expand this, ideally it would be done in agent, but probably don't want to go there...

[kareltucek]

I definitely do not want to meddle with writing into flash, since it is an easy way to brick a UHK or at least shorten its life. Also I feel that credibility of the fork could suffer from such decision.

Regarding agent, feel free to implement such thing, but as far as my time goes, I am not going to invest it into agent. Among other things, requiring modified agent would make compatibility a nightmare.

Compared to those suggestions, solving the call stack via RAM is a rather minor inconvenience. Anyway this is more bout how much resources I want to invest into the development - the firmware currently fits my needs quite well so I am reluctant to pursue features which would take huge amount of time.

[kareltucek]

In the end, I've reconsidered this and implemented a very minimalistic implementation, containing both call and exec. In this implementation, call command simply remembers its caller and returns there. No arguments, no advanced memory management.

See https://github.com/kareltucek/firmware/releases/tag/v8.5.4.kt.20