Definitely think we should have a default value system that replaces
the hack-ish use of pseudo-type characters to represent certain values
(0, -1, 1, etc.). The new-style UDOs would definitely be easy to
update for this from the language side, something like:

opcode myOpcode(freq:i = 440, amp:i = 0.25):a
...
endop

Internally, we'd probably need to modify OENTRY to accommodate storing
the default value for a pfield. It potentially becomes an arduous task
if we fully go and replace how we declare input and output arguments,
moving away from a single string to something like an array of
argument structs. Migration would be a pain, but the end result would
be a much clearer and flexible way to deal with arguments to opcodes
in our system.

On Mon, Nov 25, 2024 at 7:29 AM Eduardo Moguillansky
<eduardo.moguillansky@gmail.com> wrote:
>
> Hi,
>
> Default values for parameters, together with named arguments, have been discussed before. At the moment there is no way for an opcode to define default values outside of some simple cases, like 0, -1 or 1. There are cases where all of these are actually plausible values and it is not possible to indicate that a parameter is unset at init time. I would like to propose a new variable signature, different from o/O(=0), p/P(=1) or j/J(=-1): u/U (undefined), which would receive a nan value. The opcode would check that at init time and set it to a sensible default.
>
> The same thing could be done for UDOs, although I would like to see actual default values implemented.
>
> cheers
> eduardo
>