effectfully

@GeorgeFlerovsky > @effectfully > Could you please explain how you arrived at the "Low Priority" status for this issue? I already did: > Adding new builtins is generally low-priority but...

> We'll go ahead and start that process. Incidentally, we may have some crypto experts available on our end who may be able to advise on this. @GeorgeFlerovsky thank you...

> @effectfully Am I understanding correctly, that with this PR, this issue can be done with new primops? I don't know, sorry. @kwxm do you happen to know? If not,...

@uhbif19 does [this](https://github.com/IntersectMBO/plutus/blob/6d5e14ce7457f8317892343dca83fd7619cb7102/plutus-ledger-api/src/PlutusLedgerApi/Common/Versions.hs#L77-L134) help?

It's quite apparent that there's still confusion around the discussed topic and no way forward is specified, so from what I can tell this issue was not triaged successfully, I'm...

> Like this works: > > ``` > newtype MyType a = MkMyType a > value :: MyType (MyFamily Int) > ``` > > But this does not: > >...

> I am pretty sure types representation is isomorphic, just because I refactored code as in example and it works. If they were not isomorphic in representation, it would not...

Also, note what Michael said above: > I'm not sure it would even work, since it would mean that `f :: Foo x -> b` wouldn't be able to accept...

> Sure, I will extract and provide minimal example soon. Given this response and the fact that this is a somewhat low-priority issue, I'm going to relabel it as such.

> This does not work for both for data and type family version of code: Which I think is the expected behavior? I don't see how we could possibly support...