Josh SimmonsIf your language has block expressions, why not use block expressions for all grouping! be free, parentheses! `{ x + 10 } * y`. parens can be unambiguously tuples, just like they always wanted.
zwarich@dotstdy I showed this to @ianh and he managed to temporarily convince me (without necessarily holding this opinion himself) that function calls and tuples should use `[...]` instead of `(...)`, and then `(...)` can be used for blocks, after which your same idea applies. Were Lisp M-expressions right all along?
@dotstdy @ianh Has any recent language adopted uncurried single arg style where product types are used for multiple args rather than implicit currying? I know that Swift originally started in this direction, but I forget the actual reason why they backed away from this. Can you refresh my memory, @joe ?
Jonathan Müller@zwarich @dotstdy @ianh @joe Related, but why isn't first class multiple return values a thing more often?
For example, the C++26 standard library has senders/receivers which essentially work via continuations, so you can write async functions that take N inputs and M outputs natively without resorting to tuples. You can even send outputs of different types without having to box them into a sum type (because they just statically dispatch to different overloads).
@foonathan @dotstdy @ianh @joe My guess has always been that first-class multiple return values are overlooked because tuples serve their use case fairly well. When I think of use cases for them, my mind always goes to alternate ABIs like returning bools in status flags, etc.
Joe Groff (1M Context)@zwarich @foonathan @dotstdy @ianh I’m finding that ownership and lifetime dependent values really stretch the equivocation between tuples and multiple values. a tuple of borrows can’t always be used as a borrowed tuple, for instance
@joe @foonathan @dotstdy @ianh I think most languages that would allow you to return borrows would let you also store them as struct fields, etc. and just add a borrowed pointer type, in which case you could just make a tuple of borrows. I guess you could take a purist "parameter modes" approach and define borrowed struct fields via parameter modes on the struct's constructor? However, I think it might be tricky to make this work well with generics.
Another place where a similar distinction comes up is in-place construction of return values. Rust doesn't have this, but I assume that some successor language will want this to support internal self-reference, e.g. for efficient containers with inline capacity
@zwarich @foonathan @dotstdy @ianh yeah return value emplacement was the other thing i had in mind where a tuple (in its naive unexploded representation) isn't the same thing as multiple values.
even with first-class borrows, the way swift tries to allow for tuples to be magically exploded and imploded by the implementation fights against the very concept of a borrow-of-tuple ever existing, since you really want a contiguous representation for that borrow to refer to
@joe @foonathan @dotstdy @ianh Another funny realization is that if all return values are returned by writing to a passed reference, then you could have functions with no actual return values and only out-params (with the appropriate pointer type that must be written before returning). It's the use of resources like registers (which may be implicitly used by other code in the function) that necessitates presenting a value at the point of return.
You could take this to the next level and actually have out-params that "steal" registers when written to, but at that point you're probably in meme language territory.
@zwarich @foonathan @dotstdy @ianh hylo apparently runs with that out-params-only idea. it doesn't sound totally unworkable
@joe @zwarich @foonathan @ianh is there a "bundle" of parameters anywhere really? I was thinking yesterday about how in some amount of code, the thing you want is to control representation, and then structs / tuples / arrays make sense. But sometimes you just want to bundle things together so you can avoid gigantic lists and the associated copy pasta. Languages like Rust are kind of inheriting a lot of representation based thinking and then trying to wind it back with sometimes magic.
@dotstdy @joe @foonathan @ianh In the dependently typed world, there's a notion of internalizing a portion of the type context as a telescope (https://agda.readthedocs.io/en/latest/language/telescopes.html), or iterated dependent pair. You could probably do something similar with second-class records in a curly brace language, although you'd probably want to have both positional and named fields. In order to support parameter/result modes, you'd need to also support them on the fields of these second-class records.