Just foxing about.
Comment by ~icefox on ~icefox/garnet
Almost certainly someday:
- Make loops/break statements able to return a value
Ticket created by ~icefox on ~icefox/garnet
Right now it is an explicit goal to have very little syntactic sugar until I am very sure about the syntax and semantics to begin with
Almost certainly someday:
- elide
: {}return types for functions returning unit- Elide type decls from
letexprsMaybe someday:
- Rethink
:denoting return types for functions, it gets a little clutter-y
Comment by ~icefox on ~icefox/garnet
Between 1ML and other things, I seem to have slowly converged on something resembling ML modules, for the moment. The key question is "what are the fundamental objects the language manipulates"? In Rust there's kinda a lot: there's functions, consts/globals, then also modules, types, traits, probably some other things I'm forgetting. What if there were only values and types? Well then, how do you do modules? Well modules can just be structs that are always evaluated at compile time. This lets you have "associated types", and to some extent generics, that are just first-class types that can be guaranteed to be evaluated at compile time. With that constraint, you can use any normal language construct with them. Functors become plain functions.
This turns out to work, and basically end up being ML modules, which are actually pretty okay but IMO hampered by poor ergonomics from both the "module language" distinction and also the kinda weird specification of scopes/types (a Self type is syntactic sugar but also really useful) and also the kinda weird handling of what is and is not public/transparent. The 1ML paper demonstrates that you don't actually need a separate "module language" for them, just a bit of disambiguation sugar. I'm totally fine with disambiguation sugar in moderation, so I'm just operating based on the idea that it will work out in the end.
The main difference between ML modules and Haskell typeclasses/Rust traits is the latter dispatch based on types, and in the former dispatch is always explicit. As far as I can tell. Apart from that they largely do the same things! Not dispatching on types is honestly a little inconvenient, but isn't a bad basis for a language, so let's roll with it for now and see how it goes. It fits with our current theme of "less sugar, more explicit stuff, fewer magic constructs". Also the explicit nature of ML modules solves Haskell/Rust's "coherence problem" with traits, which is nice.
My gut feeling is still that traits are a major source of complexity in Rust, which is a little frustrating. But my impression from reading obtuse papers is also that if you have generics with typeclasses, or generics with ML modules, both result in basically the same complexity issues. So, oh well. For my goals right now, "complex and explicit" is better than "complex and implicit", so I'll roll with it and see how it works.
Comment by ~icefox on ~icefox/garnet
Something also to consider: Have a
stdliband a semi-officialcontribof high-quality third-party projects. Rust has talked about this several time but no single contrib ever unified and gained momentum.
Ticket created by ~icefox on ~icefox/garnet
They're real nice and deserve more play.
They also have some utility outside of just putting together and taking apart bit streams. What if each struct had a bitpattern that represented it, and you could cast between structs that had matching bitpatterns?