Just foxing about.
Comment by ~icefox on ~icefox/garnet
...actually a basic impl might not be too hard. If a non-Copy variable ends up on the right side of an assignment or function call, it gets marked as 'moved' and type checking keeps track of it.
Now I need some kind of effect system to track whether a type is Copy or not...
Comment by ~icefox on ~icefox/garnet
This and the previous posts in that series are really interesting. Learn more about SML and OCaml's modules. As far as I'm concerned, having modules be the compilation unit and modules form a DAG is just fine, but there's space to wiggle here.
Ticket created by ~icefox on ~icefox/garnet
Basically, what layers do we want to make it degrade gracefully?
First off, I think that instead of rust's
std/alloc/coresplit, withstdre-exporting all the things below it, the divisions should be explicit and multi-layered. If part of the lib isn't available on a platform, then it just doesn't exist. Conversely, if a program doesn't need part of the lib, then it just doesn't use it, and it's easy to determine at compile time that it's unnecessary.Thoughts so far:
core: Fundamental stuff that doesn't need anything but computation. Analogous to Rust'score. Everything requirescorealloc: Stuff that requires a memory allocator but nothing more than that.thread: Threading and associated primitives.sys: OS provided functionality. File/network I/O, timekeeping, process management, etc....I was thinking of breaking it down further but don't remember how now. So, a platform like web browser would have
coreandalloc, but notthreadandsys.
Ticket created by ~icefox on ~icefox/garnet
It would be surprisingly appealing if there were no methods, traits, or anything like that... just data structures, functions and namespaces/modules. Look at OCaml's modules for inspiration perhaps.
It didn't start related, but various people on the unofficial Rust #lang-dev discord pointed out that types and modules can be connected, and this is kinda what OCaml does. So then you start thinking about generics and templates as an offshoot of your module system.
Data is data. Functions change data. Modules are collections of functions and data. Now... if functions are also data, and modules are also data (and ergo functions), then life gets Interesting. Lua and OCaml both do some of this metaprogramming. Especially if types are also data, then you can write a function
specialize(module: M<?>, type: T> -> M<T>.And a rust-style trait becomes a compile-time function to check whether a type fulfills its constraints,
trait_applies(module: M<?>, type: T) -> Result<M<T>, CompileError>.mmmmman, and all this came out of the thought of just
what if I didn't have methods?
Comment by ~icefox on ~icefox/garnet
Related:
Evrey: @icefox Make them tuple variants with structs inside, then you at least don't have to unpack the individual fields. icefox: That's an improvement but it still just shuffles the tedious bookkeeping around.
I think Garnet is going to have C-Like enums, then Real Enums that only take a single value, plus a RealEnum::discriminant(&self) -> CLikeEnum method, and also some way of going the other way around. And structs and tuples that are interchangable.
I guess I'm thinking that if you have the ability to do
SumType{a,b,c} <-> CLikeEnum, {a|b|c}andstruct {a:A,b:B,c:C} <-> tuple (A,B,C)then a lot of tedious bookkeeping vanishes, or at least can be automated. Maybe add something like Python's swizzle operators too.Differentiating
C Like enumsasenumandReal sum typesassumseems like a good idea.