Since neither can be greater than four, all possibilities could be expressed with a two-digit number, so the syntax could be, say, FUNC 31 for 3 inputs, 1 output. The number of inputs and outputs could be parameterized pretty easily. (01-11-2021 01:15 AM)rprosperi Wrote: Regarding the features themselves, I agree with one of Pauli's comments, why not include FUNC3 and FUNC4, for (not common, but still happen) situations needing more arguments? It's just a matter of time before someone needs them, so why not add them at the start of all the testing, trying to break them, etc.? Regarding state files, do you mean there is a new state file format, or merely that the new s/w version will write non-backward compatible state files, which is understandable? Regarding the features themselves, I agree with one of Pauli's comments, why not include FUNC3 and FUNC4, for (not common, but still happen) situations needing more arguments? It's just a matter of time before someone needs them, so why not add them at the start of all the testing, trying to break them, etc.?įor multiple output arguments, a general case seems much harder to anticipate. Thanks for these enhancements Thomas, well thought-out as usual. Please feel free to share your thoughts here! Note that this introduces a new state file version, so be sure to save your existing state before using this if you want to be able to go back to using the previous version after looking at this one. These changes will be in the next release, but I've put a test build up at for testing. So, a caller can use flag 25 to catch errors raised by RTNERR, while functions can use, or not use, flag 25 internally as they see fit, and these usages will not interfere with each other. To help implement robust error handling, flag 25 is saved (and cleared) by FUNC0/1/2, and it is restored upon RTN. all four stack registers and LASTx restored, regardless of which of the three functions was used. Note that when a function terminates with RTNERR, the stack contents saved by FUNC0/1/2 will be restored to their original state, i.e. If the function was called from a program, the error message will be displayed and execution will halt on the calling XEQ if the function was called from the keyboard or from SOLVE or INTEG, execution will halt on the RTNERR (except for the errors trapped by SOLVE, as usual). The error message is selected using a number in X, as follows: RTNERR allows a function to raise an error message. The reason RTNYES is a separate function is because of its behavior when the function was XEQ'd from the keyboard: in that case, RTNYES will display the message "Yes" ans RTNNO will display the message "No". In terms of the flow of control, RTNYES acts just like RTN, while RTNNO returns to the line after the one RTN would return to, skipping the line right after the calling XEQ. RTNYES and RTNNO allow a function to behave like a conditional. The stack restoration happens automagically upon RTN. Thus, in order to implement a binary operator, all that's needed is to call FUNC2 at the beginning of the function, and make sure the result is in X when it returns. Upon RTN, a function initialized with FUNC0 will restore all four stack registers and LASTx to their original values a function initialized with FUNC1 will leave X intact, restore the original X to LASTx, and restore Y, Z, and T to their original values and a function initialized with FUNC2 will leave X intact, restore the original X to LASTx, and restore T to T and Z, and restore Z to Y. The descriptions on my web site cover the implementation in the official 2.5.23 release the following documents the implementation in my current prototype:įUNC0, FUNC1, and FUNC2: These functions preserve the stack and LASTx, in preparation for restoring registers when the function returns. I wasn't happy about it and made several improvements, in the areas of error handling and RTN behavior. The implementation of these functions in 2.5.23 is functional, but flawed. The idea is to make it easier to implement the proper stack behavior, and to allow subroutines to return error codes and to act as conditionals. In Free42 2.5.23, I introduced a few new functions that are meant to help create subroutines that behave like built-in functions.
0 Comments
Leave a Reply. |