Remove listLenBound from EncCBORGroup class

[f-f]

Description

Fix #5372

Checklist

• Commits in meaningful sequence and with useful messages.
• Tests added or updated when needed.
• CHANGELOG.md files updated for packages with externally visible changes.
  NOTE: New section is never added with the code changes. (See RELEASING.md).
• Versions updated in .cabal and CHANGELOG.md files when necessary, according to the
  versioning process.
• Version bounds in .cabal files updated when necessary.
  NOTE: If bounds change in a cabal file, that package itself must have a version increase. (See RELEASING.md).
• Code formatted (use scripts/fourmolize.sh).
• Cabal files formatted (use scripts/cabal-format.sh).
• CDDL files are up to date (use scripts/gen-cddl.sh)
• hie.yaml updated (use scripts/gen-hie.sh).
• Self-reviewed the diff.

[f-f]

CI seems happy so I think this is good for another look

[lehins]

There is really only one suggestion that I have, which I repeated multiple times. Other than that it looks great!

[f-f]

@lehins asProxyTypeOf was not what we needed, so I have defined this toProxy here. I'm pretty sure this is not the right place, so let's figure out where it needs to move or if it should be defined in every module where we need it

[lehins]

Yes, I totally agree with the fact that this is a better function for us than asProxyTypeOf. I tend to avoid defining things that are already available in some form in base, even if they are slightly worse then what I need.
The reason why I avoid it is because I am too lazy. 😅
There are two very hard problems that needs to be solved when one creates a generally reusable function like this 🤣

• Finding a good name
• Finding where to put it

The irony about this function, is that I have defined a function just like that in the past toProxy, which doesn't really help us here, but still funny 🥲

In order to stay consistent with the name in base, I think it would be better to call this one asProxy instead. And, as of recent developments, there is a really good place where we can put it, we created a package cardano-base.

With all this in mind, I think it would be a prefect time for you to make this small contribution in a place other than ledger. So, please:

• add a module Cardano.Base.Proxy in cardano-base package.
• add this function there and re-export all of the stuff from Data.Proxy.
• make a release of that package to CHaP and tag me on the RP for approval
• Update index-state and nix flake in cardano-ledger, once release has been merged and start using this asProxy function in this PR.

FTR. We don't normally go through all these troubles just to get one function form some place. I am only suggesting you do this to get familiar with the process of making release to CHaP and pulling in newer dependencies in

[lehins]

Looks like I missed one more suggestion. Using Proxy @a would have been fine, it is the fromIntegral . toInteger that is totally unnecessary here, which was there before this PR.

Suggested change

	decodeRecordNamed "CBORGroup" (fromIntegral . toInteger . const (listLen $ Proxy @a)) decCBORGroup
	decodeRecordNamed "CBORGroup" (listLenInt . (`asProxyTypeOf` Proxy)) decCBORGroup

[lehins]

Yes, I totally agree with the fact that this is a better function for us than asProxyTypeOf. I tend to avoid defining things that are already available in some form in base, even if they are slightly worse then what I need.
The reason why I avoid it is because I am too lazy. 😅
There are two very hard problems that needs to be solved when one creates a generally reusable function like this 🤣

• Finding a good name
• Finding where to put it

The irony about this function, is that I have defined a function just like that in the past toProxy, which doesn't really help us here, but still funny 🥲

In order to stay consistent with the name in base, I think it would be better to call this one asProxy instead. And, as of recent developments, there is a really good place where we can put it, we created a package cardano-base.

With all this in mind, I think it would be a prefect time for you to make this small contribution in a place other than ledger. So, please:

• add a module Cardano.Base.Proxy in cardano-base package.
• add this function there and re-export all of the stuff from Data.Proxy.
• make a release of that package to CHaP and tag me on the RP for approval
• Update index-state and nix flake in cardano-ledger, once release has been merged and start using this asProxy function in this PR.

FTR. We don't normally go through all these troubles just to get one function form some place. I am only suggesting you do this to get familiar with the process of making release to CHaP and pulling in newer dependencies in

[teodanciu]

Why not a Proxy here too, instead of a value a? Isn't it misleading like this, as if the value is taken into consideration?

[f-f]

Good point - though I find that not having to pass the proxy is half of the convenience of this function: it then becomes fromIntegral . listLen, and I think I'd rather just remove it at that point?

[lehins]

I agree with both of you. That's why I think the best approach here will be to make it:

Suggested change

	listLenInt :: forall a. EncCBORGroup a => a -> Int
	listLenInt :: forall proxy a. EncCBORGroup a => proxy a -> Int

This will allow using it with concrete types instead of just Proxy, e.g.

  Plain.decodeRecordNamed "OCert" (listLenInt . Just) decodeOCertFields

or Identity a, if Maybe a feels too hacky:

  Plain.decodeRecordNamed "OCert" (listLenInt . Identity) decodeOCertFields

This will keep it consistent, while still allow for convenience to use the value for inferring the type.