~icefox

Just foxing about.

https://wiki.alopex.li/

Trackers

~icefox/garnet

Last active 11 days ago

~icefox/oorandom

Last active 5 months ago

~icefox/scalar

Last active 1 year, 9 months ago

~icefox/cf_issues

Last active 3 years ago

#35 Syntax sugar to work on 11 days ago

Comment by ~icefox on ~icefox/garnet

Almost certainly someday:

  • Make loops/break statements able to return a value

#35 Syntax sugar to work on 11 days ago

T-LATER added by ~icefox on ~icefox/garnet

#35 Syntax sugar to work on 11 days ago

T-DESIGN added by ~icefox on ~icefox/garnet

#35 Syntax sugar to work on 11 days ago

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 let exprs

Maybe someday:

  • Rethink : denoting return types for functions, it gets a little clutter-y

#17 Thoughts on type metaprogramming 19 days ago

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.

#9 Thoughts on stdlib 19 days ago

Comment by ~icefox on ~icefox/garnet

Something also to consider: Have a stdlib and a semi-official contrib of high-quality third-party projects. Rust has talked about this several time but no single contrib ever unified and gained momentum.

#34 Steal Erlang's bit patterns a month ago

T-DESIGN added by ~icefox on ~icefox/garnet

#34 Steal Erlang's bit patterns a month ago

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?

#14 Can we make the build and package system for this just be cargo? 3 months ago

Comment by ~icefox on ~icefox/garnet

#1 Type inference 5 months ago

Comment by ~icefox on ~icefox/garnet

Moved to wiki

REPORTED RESOLVED FIXED