#9 Thoughts on stdlib 2 days ago

Comment by ~icefox on ~icefox/garnet

It was suggested that I take a look at Julia's I/O and net libs, might have some inspiration there.

#9 Thoughts on stdlib 2 months ago

Comment by ~icefox on ~icefox/garnet

Oh now here's a hornet's-nest issue: What does the license for contrib have to be? I will tentatively say LGPL; if it's good enough for SDL then it's good enough for me, and SDL is a good example of LGPL code being widely used in both industry and open-source.

#9 Thoughts on stdlib 2 months ago

Comment by ~icefox on ~icefox/garnet

More thoughts on contrib (maybe call it batteries): have a specific set of design criteria and goals for it, admit that they may need to change over time, and use semver to let people use different versions of it.

Goals:

• Bug-free, easily auditable, heavily tested and fuzzed
• Minimalist -- this may be the wrong decision but it seems like an okay place to start
• Cross-platform -- as much as is feasible anyway.
• Semver-compliant -- preferably in an automated way.
• Sensible defaults -- without having a million different options

Anti-goals:

• Platform-specific -- an example would be a nicer API over POSIX specific filesystem handling
• Ultra performance -- Things should be as fast as they can be while adhering to the goals
• 100% complete -- this is a library for people to start with, not to be the end of everything.
• Huge -- this should not become infeasible to maintain.
• Hip -- This is not a place for experimental tools, it is a place for basic utilities

This also needs policies to maintain these goals. Criteria for inclusion: Informal agreement of the maintainer to maintain it for a year.

Criteria for removal: Packages will be reviewed once per year. If a package is no longer maintained, can be replaced by a totally better one, or has been found to have unfixable bugs/misdesigns that introduce security problems, then it should be removed. (This list is probably incomplete.) If a package is replaced by a totally better one three years in a row then the ecosystem is probably not mature and that category of package should be removed for a while.

Examples of packages that should be included:

• zstd: Basic compression stuff. Maybe zip/deflate/etc too... maybe not? Opinionated, remember
• rng: PRNG with some good algorithm
• secure-rng: a way to get secure randomness from the OS
• hash: sha256 and 512
• alternate hashtable algorithms for no more than 2 different common use cases
• command line arg parsing: preferably in a way that makes it easy to conform to a single format.
• http/etc clients and servers

Maybe included:

• image/media/etc codecs???
• Ugly but cross-platform GUI a la Tk?
• Templating language?
• Lua interpreter bindings? Would be interesting to make this available to everyone as a matter of course.

Not included:

• Big GUI a la Qt
• Rust's rand crate -- too many unneeded options
• Rust's clap crate -- too many unneeded options
• Rust's error_chain crate -- Has been superceded by new designs every year for years
• Rust's tokei -- Big and do-everything for async

#26 Implement fuzzing 5 months ago

Comment by ~icefox on ~icefox/garnet

That looks ideal, thanks for the tip!

#19 Figure out (basic) errors/panics 6 months ago

Comment by ~icefox on ~icefox/garnet

Interesting conversation and design stuff in this article: https://lobste.rs/s/8mqgal/different_ways_handle_errors_c

#35 Syntax sugar to work on 7 months 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 7 months ago

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

#35 Syntax sugar to work on 7 months ago

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

#35 Syntax sugar to work on 7 months 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 7 months 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.