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.
Slava Pestov@zwarich @joe @foonathan @dotstdy @ianh My prediction is that at some point in the next 5 years this whole “systems language” fad will blow over as programmers get tired of constantly being forced to deal with value semantics and unique ownership, and they’re going to rediscover the simplicity and elegance of garbage collection with uniform tagged pointers, at which point they’ll give this paradigm some really dumb name and pretend it’s brand new
@slava @zwarich @foonathan @dotstdy @ianh i think there's another local optimum in the Rustlike space if you steered the ecosystem toward coarse-grained ownership, where most values are owned in bulk by arenas or GC regions, and individually managed resources are the minority
@joe @slava @foonathan @dotstdy @ianh This is one of the things I'm trying to do in my new language. There are a few new features required, e.g. variable-dependent types (so that indices into an arena can depend on the arena instance), coeffects/implicit context and coeffect polymorphism, "linear" types, etc.
I am hoping this will remove a lot of the complexity of a language like Rust and look more like the C/Zig one would write (except now with static checking), but I'm sure there will be ways in which things are more complicated compared to an "isolated ownership" language like Rust.
shac ron ₪@shac @joe @slava @foonathan @dotstdy @ianh To be a bit more serious, I think it’s hard to predict how easy things will be to understand in advance. When you implement a language, you are usually spending a lot of your time thinking about the dark corners of features or rare interactions between them rather than the phenomenology of actually writing programs.
As an example, I never would have guessed that Rust would reach the level of adoption it currently has outside of its original niche. While a lot of this is due to features outside of its initial value proposition or the wider ecosystem, the people that come for these reasons still have to put up with everything else.
Since I’m making an inherently weird language, I’ve adopted a few principles to make it more understandable:
1) Avoid prematurely adding features like type classes/traits that invite an endless horizon of potential generalizations but don’t have much to do with my basic thesis.
2) Constantly look at everything I have in the language and try to refactor it by reusing common technology, even if this enables users to do things that seem useless to me. To go back to Rust, since its development is the result of a sometimes contentious social process and constrained by strict backwards compatibility, it is incredibly asymmetric.
3) Plan the development of the language in stages, where at each stage I am building something that is actually useful and internally consistent, but is also deliberately missing features that I plan to add in later stages.
I guess I should actually write a post about my goals and ideas. I previously told myself I don’t want to release anything until I have a bootstrapped self-hosted compiler, but maybe that’s too conservative.
gok@doctorgoktor @shac @joe @slava @foonathan @dotstdy @ianh My basic thesis is that it's possible to make a safe programming language that enables many of the standard programming patterns for improving performance that might be labelled "data-oriented design", e.g. using arenas (including with indices rather than pointers), stealing bits from pointers, AoS/SoA transposition, rare parts of structs that live externally, etc.
I have lots of other smaller theses (including some just related to the implementation techniques rather than the user experience), but this one is the core because if I fail to achieve it then I don't think there is enough to distinguish it from other languages.