- 24 Apr, 2020 1 commit
-
-
Eric Myhre authored
These are getting increasingly straightforward as most of the hard problems have been ironed out already when getting the other recursives (maps and structs) sorted. Now, we just need to stamp out the rest of the scalars, and I think this codegen stuff is at least early-alpha level usable! Also in this commit: added some new error types and fixed up the basicnode.List implementation to use it, removing some todos there.
-
- 19 Apr, 2020 1 commit
-
-
Eric Myhre authored
Fixes many issues with maybes. Some minor typo-scale stuff; some pretty consequential. What to do about speciated lookup methods still has big honking questions on it: returning a maybe there if you didn't already have data in that format can be *not cheap*. Figuring out the best DX there is gonna be interesting. Making progress on how to handle keys, but slow. Complex keys are... well, really complex. So far I've learned several things that *won't* work, which is fun. It's looking unlikely that having a KeyAssembler type at all is actually going to be a good idea.
-
- 13 Apr, 2020 3 commits
-
-
Eric Myhre authored
This diff is pretty fun. It's our first alternative representation, and it all works out nicely (no internal syntactical complications encountered or any other unexpected unpleasantness). It's also our first representation that involves potentially recursive destructuring work over a scalar! So, you can see the new 'construct' method conventions appearing to handle that. Works out neatly. This kind of recursive destructuring happens all within the span of processing one "token" so to speak, so naturally it can work without any stateful machinery. Some utility functions are added to the mixins package. (It's sort of betraying in the name of the package, but, well, it's an extremely expedient choice. See comments about import management. tl;dr: consistency makes things easier.) Tests for a recursive case of this will be coming soon, but requires addressing some other design flaws with the AdjunctConfig maps. (StructField is... not a good key. It's not always hashable... such as when the StructField.Type field is inhabited by TypeStruct.) Easy enough to fix, just not going to cram it into this commit. The way null and the 'fcb' are handled here differs from previous generators: here, we *always* have an 'fcb', and just make a special one for the root builder. This is... well, it works. It was an attempt to simplify things and generate fewer method overrides, and it did. However, I'm not going to dwell on this too long, because... The 'fcb' system is not working out well overall for other reasons: it's causing costly allocations. (Taking a function pointer from a method requires at least two words: one for the function pointer and one for the value to apply it on. That means an allocation.) So a serious rewrite of anything involing the 'fcb' strategy is needed. And that is going to be a little tricky. The 'fcb' idea was itself a trying-slightly-too-hard-to-be-clever attempt to avoid an alternative solution that involves generating additional types per distinct child value slot (and I'm still unwilling to pursue that one -- it suggests far too many types). The next best idea I have now seems to involve a lot of pointers into other assembler's state machines; this will surely be a bit touchy. But no worse than any of the rest of all this, I suppose: it's *all* "a bit touchy". Buckle up for fun diffs ahead.) So, considering these 'fcb' notes, this feels a bit mixed... "Two steps forward, one step back", so to speak. Still: progress! And it's very exciting that we got through several new categories of behavior without hitting any other new roadbumps.
-
Eric Myhre authored
-
Eric Myhre authored
I'll want this momentarily for doing Generate from other packages. (I might not actually commit anything relating to this for a while, but secretly, I'm playing with it.) Correct a half-dozen laxnesses in path handling while at it.
-