~icefox

Just foxing about.

https://wiki.alopex.li/

Trackers

~icefox/garnet

Last active 3 days ago

~icefox/oorandom

Last active 22 days ago

~icefox/cf_issues

Last active 1 year, 3 months ago

#10 Move semantics 3 days ago

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...

#10 Move semantics 7 days ago

TODO added by ~icefox on ~icefox/garnet

#10 Move semantics 7 days ago

Ticket created by ~icefox on ~icefox/garnet

oh gods

#8 Thoughts on modules 9 days ago

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.

#9 Thoughts on stdlib 10 days ago

THOUGHTS added by ~icefox on ~icefox/garnet

#9 Thoughts on stdlib 10 days ago

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/core split, with std re-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's core. Everything requires core
  • alloc: 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 core and alloc, but not thread and sys.

#8 Thoughts on modules 12 days ago

THOUGHTS added by ~icefox on ~icefox/garnet

#8 Thoughts on modules 12 days ago

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?

#7 Thoughts on matches/tree-walking (and data in general) 12 days ago

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} and struct {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 enums as enum and Real sum types as sum seems like a good idea.

#7 Thoughts on matches/tree-walking (and data in general) 12 days ago

THOUGHTS added by ~icefox on ~icefox/garnet