Multi-Return 2026: It's Good, But Could It Be Better?

Development Functions
1

So I've gotten more enamored of this idea with time.

Looking at something from the tests:

export do-recover: func [
    "Executes tests in the FILE and recovers from crash"

    return: [
        ~(
            file! "log file"
            text! "textual summary of results"
        )~
    ]
    file [file!] "test file"
    flags [block!] "which flags to accept"
    code-checksum [<opt> blob!]
    log-file-prefix [file!]
] [
    ...
]

With multi-return being such a powerful feature, it would be a shame if we didn't do better than that for exposing it.

I was actually contemplating the meaning of not having the word RETURN: on the interface at all, when you use these proxying results:

export do-recover: func [
    "Executes tests in the FILE and recovers from crash"

    {log-file}: [file!]
    {summary}: [text!] "textual summary of results"

    file [file!] "test file"
    flags [block!] "which flags to accept"
    code-checksum [<opt> blob!]
    log-file-prefix [file!]
] [
    ...
]

If there's typechecking, we can make sure you've done assignments. Then maybe there's no worry about calling RETURN. It could be arity-0, and not favor one of the returns over the other.

Lots To Think About...

But one of the biggest thinking points would be "could we get those names on the interface, and could those names be part of the contract between caller and callee".

Going down memory lane a bit, the "old" way of doing such a thing would be to publish those as slots you could put variables in on the frame:

>> f: make frame! do-recover/

>> log: sum: ~

>> f.log-file: $log
>> f.summary: $sum

Then you fill the rest of the frame fields and do eval f or you say run f blah blah blah blah or /f blah blah blah blah or whatever.

Among the many things that kind of sucked about that was that then you'd have to say inside the body of the function set log-file whatever instead of just log-file: whatever.

But at least for that problem... Now we have ALIAS. Though generally speaking, calling functions with aliased variables in FRAME! will fetch the aliased variable out... we don't make things like natives consider aliases in their frame cells, they assume they are resolved cells.

Other problems remain though (such as that if a failure is encountered during the function's execution, the multi-return's effects can have already taken hold).

:thinking:

1 Like