I have a potential 0.19.3 here and I need to decide if I should go ahead and release it basically as is, or if I should add more to it.
The overall project with 0.19.x releases is “get the compiler more aligned with Acadia” since that will unlock more interesting projects. (E.g. support UInt32, Int64, and other primitive numeric types. See about converting elm-simple-server into server module in Acadia. Etc.)
The actual changes here are in two categories:
More explicit binary encoding/decoding. The typical libraries in Haskell for binary do everything with type classes, so it’s hard to have more sophisticated binary formats without goofing up your types in your program. So this branch switches to binary encoders/decoders that I wrote by hand to be more in the Elm style, where every choice is explicit. They appear to be a little faster, but that’s not really the goal.
Using more precise types within the compiler. So instead of having a Name type for all different names, there are now separate types for module names, variable names, type names, etc. I also manage concurrency a bit differently so that crashes will get reported in a better way. I also have better computation of “minimal cycles” for whenever you have a complex cyclic value or cyclic modules.
The net effect is that it’s a tiny bit faster, the binary formats are a little different, and I can close a handful of bugs. I do not feel satisfied with the “narrative meaning” of these changes though. Maybe emphasizing that it helped resolve a couple issues. Maybe emphasizing the type Name = Name String approach that is possible in Elm/Haskell, but basically not doable in TS. I need to think about it more.
Which aspects of this sound more or less interesting?
If the changes don’t themselves have a big narrative or exciting speedup etc., I’d maybe think of the release as cleaning up your table (a non-problematic upgrade making things slightly faster but mainly making the codebase nicer for you) so 0.19.4 or 0.20.0 can be focused on the big things. I’m sure people will be able to sympathize with that
EDIT: I’d definitely love to read something about the newtypes, ID/Name safety, primitive blindness etc.
I need to decide if I should go ahead and release it basically as is, or if I should add more to it.
If you were to add more to it, what would be the candidates for the next thing(s) you might add? If there’s a next thing that potentially strengthens one of these narratives, maybe it’s worth bundling up into a bigger release.
Also, I guess it depends who the narrative is for. I think people in the Elm community will be excited about the details of any new release, however small, and fixes for any long-standing bugs will be gratefully received. But if you’re looking to attract new people, I think it might be better to major on the “roadmap for aligning Elm & Acadia” angle.
I think this is the narrative that is most interesting. Rather than these internal compiler changes themselves, its the goal that you are working towards that is the intriguing part. If you are comfortable making such forward looking claims.
[goal: I’d like to learn]
I only ever used json and xml in elm, so I may be lacking some context, but I have no idea what this means for elm. Could someone explain please? Does it affect how e.g. protobuf works in elm?
[goal: providing feedback]
I would enjoy such a blog post too. Especially if you have some insights into the limitations of TS. (I know of two approaches to achieve this in TS: adding anything private to a class, or something with the unique symbol type. But never understood the exact type-system stuff behind them, or how reliable those approaches are)
But if it is truly just “making the codebase nicer for you”, then we all already benefit from this change, even if you don’t release it
I don’t think it affects how Elm works at all. Its just changes within the Elm compiler, which is written in Haskell, to improve how it does binary codecs - which it uses to read and write the .elmo and .elmi files you see inside of elm-stuff/ and some others too.
