It’s somewhat annoying that you can’t take an arbitrary expression and prefix something to it with constant &&& expression. This would require that the expression have the same input type as constant, which if constant is a const-word jet, is unit.
This also means that the source type of an expression created by the Rust scribe method (and presumably the Haskell one as well) is nonobvious – it will be unit if any constant-word jets were used but it will be free otherwise.
It’s easy enough to work around this by composing with unit, as (unit; constant) &&& expression but it’s a minor papercut.
1 Like
So the normal jets have fixed input and output types because otherwise, if they had polymorphic types then the jets would have to do arbitrary and variable amount of work copying data from polymorphic inputs to polymorphic outputs, depending on the type instance. This would vastly complicate their cost model.
Now, it is true that constant jets, such as constant word jets, wouldn’t incur this cost since ignoring their input doesn’t cost anything. However, to keep the specification format for jets consistent across all jets, I decided to fix the input and output of all jets uniformly.
Since constant word jets are in some sense special, they have a fairly special encoding as nodes, we could have made a distinct class of nodes for these constant words that would allow them to have polymorphic inputs, and I think that is a valid design choice, and might even be worth pursuing in a future iteration of Simplicity. But at the time, I just decided to have constant word jets work in exactly the same way all other jets work.