README proofreading, and a question about hypertypes HOT 5 CLOSED

Another way of describing it, is that just like we find ourselves needing mutually recursive AST types, we also sometimes find ourselves in the same situation with the fix-points. And this approach enables the same power for both.

from hypertypes.

At one point, there is the sentence: "Some extensions we use but would like to avoid (we're looking for alternative solutions but haven't found them):", but then there is nothing following the colon.

Oh, yes that accidentally remained from when we've used UndecidableSuperClasses. Fixed now, thanks!

And something I started wondering about: how does the hypertypes approach compare to the "HKD for nested structures" approach?

The only listed drawback of the latter is that Rank2.Functor doesn't work for it. Ok. (Could you write a separate class?) But apart from that...

...
If I were to hazard a very rough guess, maybe the HKD approach is fine as long as you only want to alter the shape in "regular" ways, in some sense, while hypertypes in addition lets you do fancy tricks with the underlying fixpoints...?

A few more simple examples of things that you can't do with "HKD for nested structures":

• hzip :: (h # p) -> (h # q) -> h # (p :*: q). In addition to not being able to declare a type-class for it (which is the same issue as with Rank2.Functor), you can't even represent the result type because one can't have a fix point that contains two subexpressions each with a different fix-points.
• Use data Diff a b e = CommonSubTree (Ann (a :*: b) e) | CommonBody (CommonBody a b e) | Different ((Ann a :*: Ann b) e) as the parameter, another fix-point which can use different fix-points for the child nodes,

Don't know whether those count as fancy tricks.

A bit further down, "one would have to declare an explicit expression type for each expression type for use as ...". Was a sentence fragment accidentally duplicated here? (If not, maybe it's just a bit confusing.)

I'll look into whether I can word it better.

from hypertypes.

A bit further down, "one would have to declare an explicit expression type for each expression type for use as ...". Was a sentence fragment accidentally duplicated here? (If not, maybe it's just a bit confusing.)

I changed the wording now, is it better?

from hypertypes.

Yeah I think so!

Don't know whether those count as fancy tricks.

This is the kind of thing I was suspecting might be the case yeah. (I don't know if "fancy tricks" is the right term either, it's just the one that came to mind.) Thanks for elaborating!

from hypertypes.

Another way of describing it, is that just like we find ourselves needing mutually recursive AST types, we also sometimes find ourselves in the same situation with the fix-points. And this approach enables the same power for both.

from hypertypes.