Composition of plutarch functions

[sergesku]

I decided to add plutarch function composition as the first step of contribution.
Do we need it?

[L-as]

Thanks for the patch!

Unfortunately, there is an issue I'm not sure what to do about:

f (g x) is smaller than (\x -> f (g x)) $ x. Perhaps we shouldn't introduce function composition because of this inefficiency, because we want to discourage f #. g #$ x. OTOH, is there a way by which we can make it efficient? Perhaps we should nonetheless include this.

@srid @TotallyNotChase

[TotallyNotChase]

IMO, true Plutarch level composition is only really useful (and zero cost) for higher order functions taking in Plutarch functions. There is debate to be had about when HOFs benefit from taking in Plutarch level functions already, and you could ideally micro-optimize by alternating between HOFs taking Haskell level functions and Plutarch level functions.

Outside of HOFs, such as in the case of the example- f #. g #$ x, we should rather encourage-

(#..) :: Term s (b :--> c) -> Term s (a :--> b) -> Term s a -> Term s c
(#..) bc ab x = bc #$ ab # x

-- f #.. g $ x

or something similar.

I don't know if it's possible to make true Plutarch function composition efficient without more eta reductions and inlining over Plutarch functions themselves.

[L-as]

I've been thinking that Plutarch-level function application shouldn't translate to a raw RApply anymore. We want to do these kinds of manipulations with Plutarch-level functions too, albeit it would require a rewrite of Plutarch.Internal.

[kozross]

Given how common something like f . g $ x is Haskell-side, I would say that a change making it cheaper to do the equivalent Plutarch thing is worth it.

[L-as]

I agree, I will look into this when I have more time. Until then, this PR won't be merged I think @sergesku , thanks for the contribution though!