I was looking at code generation for bindings with different update flags. Update flag type is defined as:

data UpdateFlag = ReEntrant | Updatable | SingleEntry

I realized that we don't care about the difference between ReEntrant and SingleEntry, we only care about whether a binding is updatable or not, which is defined as

isUpdatable :: UpdateFlag -> Bool
isUpdatable ReEntrant   = False
isUpdatable SingleEntry = False
isUpdatable Updatable   = True

So we could remove SingleEntry and replace all uses of it with ReEntrant and everything would work the same.

This raises the question of whether we're missing an optimisation in the code generator. Looking at code generation differences of updatable and non-updatable bindings, it seems like for a thunk (a binding with no arguments) we generate a thunk header and push an update frame regardless of the update flag. As far as I can see, update flag is only used when generating AP and selector thunks (we don't generate AP or selector thunks if the binding is not updatable).

My question is: it seems to me that if a thunk is single entry then we should be able to give it a non-thunk type (maybe FUN?) and avoid pushing an update frame in closureCodeBody. Am I missing anything or is this possible? Is this worth trying?