[PlutusLedgerApi] [Refactoring] Polish imports and exports

[effectfully]

This

• resolves Export from PlutusLedgerApi.Common #6098
• moves a bunch of stuff shared among V1/V2/V3 into Common (see the PR review)
• makes all imports in the Common/V1/V2/V3 modules qualified so that it's clear where definitions come from and whether they are inherited from Common or an earlier ledger language
• fixes some formatting, adds a definition for consistency etc

[effectfully]

Made the formatting consistent with the formatting of the V1/V2/V3 modules.

[effectfully]

Made import lists explicit in this module. I normally don't care much about readability of imports, but given that it's one of the ledger API modules and it's important to keep it reasonable and readable, I thought it might be worth going full verbosity. Now it always clear where a definition comes from, regardless of whether you look at imports (due to the explicit list) or exports (due to everything being imported qualified apart from entirely trivial things, of which we only have MonadError).

Please tell me if I should remove the explicit imports or add them to other modules or keep everything the same.

[zliu41]

I thought it might be worth going full verbosity

I believe this can be enforced by HLint, so while you are at it you may want to add an HLint rule to ensure it stays this way.

Please tell me if I should remove the explicit imports or add them to other modules or keep everything the same.

In general having both qualified imports and explicit imports is an overkill, so I wouldn't do this to other modules - I don't see the need. I'm in favor of using either qualified imports or explicit imports everywhere, but others even find this to be not worth it.

[Unisay]

My take:

• Wildcard imports: mostly no, could be exceptions.
• Qualified imports: nice, should use more.
• Explicit imports: also nice, complements qualified:

import Data.Text qualified as Text

message :: Text.Text -- IMO this duplication is ugly
message = Text.toUpper "hello" -- this is readable.

the combo of qualified and explicit is what I'd use:

import Data.Text qualified as Text
import Data.Text (Text)

message :: Text -- The best 
message = Text.toUpper "hello" -- good

[effectfully]

I believe this can be enforced by HLint, so while you are at it you may want to add an HLint rule to ensure it stays this way.

Sorry, I'm fully committed to never adding HLint anywhere. I was forced to use it for months and it damaged me badly.

In general having both qualified imports and explicit imports is an overkill

I totally agree, it's just that these modules are very special in that everything exported by them must be scrutinized deeply. My usual standards for imports are lower than yours or Yura's.

@Unisay I agree with you, I'm just usually lazy when it comes to import management. Especially if it's within "standard" modules like base or PlutusCore or whatever. I'll try to do a better job.

[effectfully]

I've also reexported toOpaque and fromOpaque from here, since toBuiltin and fromBuiltin used to subsume those.

[effectfully]

Exported it from here, because it's used in all V* modules.

[effectfully]

Fixes #6098.

[effectfully]

Exported other Data-related stuff as well.

[effectfully]

This module now contains only PlutusLedgerApi imports, no Plutus Tx or base.

[effectfully]

It's now clear whether something is inherited from Common/V1 or defined by V2 specifically. I find it very useful to be able to tell whether the thing under point is inherited from an earlier version or not.

[effectfully]

I'll think what to do with this import, but perhaps nothing, it's indeed required here and not in V1.

[effectfully]

We already had toData and fromData, so I thought adding unsafeFromData and exporting it for consistency would be worth it.

[zliu41]

I thought it might be worth going full verbosity

I believe this can be enforced by HLint, so while you are at it you may want to add an HLint rule to ensure it stays this way.

Please tell me if I should remove the explicit imports or add them to other modules or keep everything the same.

In general having both qualified imports and explicit imports is an overkill, so I wouldn't do this to other modules - I don't see the need. I'm in favor of using either qualified imports or explicit imports everywhere, but others even find this to be not worth it.

[effectfully]

I've made imports either qualified or explicit everywhere, since that what I gauge is preferable.