Coding 2023-01-04

Tags:
By Max Woerner Chase

I have a hypothesis about why InputAccumulator is troublesome to rename. Let's see if it makes sense in text as well as in my head.

The problem is that it's basically a reified right fold (hey, spell check is back! Too bad it doesn't know that "reified" is a word.) Anyway, that's not the whole story, but I don't think the bits I'm leaving out matter, except insofar as they make everything more awkward.

The point is, let's have a look at how a right fold is typed in, say, Haskell. (a -> b -> b) -> b -> [a] -> b The InputAccumulator is like this, except the types are specialized and I pretended that I can have existential types. The "list" basically doesn't exist in any explicit sense, and only implicitly exists in terms of the object that gets built up. So, it's like, let's pass the function and the initial value to foldr, but it's not really foldr. It's like... (a -> b -> b) -> b -> wait actually I don't know if it's possible to express this in Haskell's type system, and I'm fairly sure most people wouldn't want to I guess the closest equivalent would be ((a -> b -> b), b) -> a -> ((a -> b -> b), b) or something, subject to additional constraints that I believe the types involved are expressive enough to not give us for free... I'm not saying that the fact that this concept is awkward in Haskell necessarily means I shouldn't do it in Python the way I'm doing it, but given the way that my hobby Python sometimes ends up looking, it does legitimately raise the question. Because the actual fold stuff is only done in one place in the code, it's not a great burden to rewrite it. (Except that I would also need to surface the possibility of mapping over the final value, which is a thing that I do sometimes because of reasons, but surely there's a more sensible way to do that, as well...)

What this would basically entail would be pulling implementation details of InputAccumulator into artifact.Output, and replacing its methods with some helper functions. This would have some side effects in which error messages make more sense, because the failures are coming from the "correct" class all of a sudden. The main issue then is how to package this up and then unpackage it for the artifact.Output, when there's no longer a single class to work with. This is going to take some more thought.

And right now, it's already way too late.

Good night.