Flesh out Plutarch.Api, port utilities #652
Conversation
use it on test suite
V1 plutus-ledger-api is no longer supported as of this PR. It is because there's no reason for users to develop and maintain script on older ledger API. V2 is strict superset of V1(and V3 is likely to be strict superset of V2) and therefore, nothing incentivizes using V1 ledger API over V2. For existing codebase that is using V1(and V2, after V3 lands), they would need to bump their codebase, adapting to new api library. Since smart contract scripts are rather static objects, meaning they are hard to change easily nor frequently, discontinuation of old ledger API on Plutarch will not break existing and deployed onchain scripts. When replacing a old script, ledger version of the new script does not need to match that of old script; therefore, new ledger api can be used to build replacement script. |
|
Woohooo staging! |
`Plutrach.LedgerApi` for better consistency
Closes #636. This is a fairly major set of changes: a lot of identifiers have moved, some have vanished altogether, and a few bits still remain outstanding. Every change has been logged, but a few are a bit more 'invisible'.
Guide to migration
Essentially, a lot of stuff that used to be in
plutarch-extrais now part ofplutarch-api. Specifically,Plutarch.Extra.Map,Plutarch.Extra.Interval,Plutarch.Extra.Apihave been wholesale ported intoplutarch-api(either a submodule, orPlutarch.Apiitself), and any part ofPlutarch.Extra.Maybeto do withPMaybeDatais now inPlutarch.Apias well. Furthermore,Plutarch.Api.*from the main Plutarch repo is now gone: everything that was there was moved toplutarch-api.Most notable change is that now, the API is V2 only. V1 stuff is gone, and all data types and functionality that differed between V1 and V2 now defaults to V2. This is a temporary measure, as we're moving to V3 in short order. This may mean some data types have changed a bit: if your old data types or functions were V1, you need to migrate to their V2 versions.
A few things have been removed altogether, as they either have no V1 equivalents, weren't useful (or covered by tests), or are otherwise no longer required:
pnever(no V2 equivalent)PTuple(typesynonym,PTuple a bis identical toPBuiltinPair (PAsData a) (PAsData b))MergeHandlers (hidden for now unless someone wants it, pending a full rethink)ptuple,ptupleFromBuiltin,pbuiltinPairFromTuple(no-ops anyway, now useless withPTuplebeing gone)PValidator,PMintingPolicy,PStakingValidator(alltypes, just use their equivalents, which arePData :--> PData :--> PScriptContext :--> POpaque,PData :--> PScriptContext :--> POpaqueandPData :--> PScriptContext :--> POpaquerespectively)IsListinstances forPMap(were broken and a bad idea to begin with, usepunsortedMapFromFoldableorpsortedMapFromFoldableinstead offromList)It is possible some functionality for
PMaporPValueslipped by us: if you need it, please let us know and we'll do our best to restore it!Outstanding tasks
In light of this PR landing, there are some remaining things to do:
PMapfunctionality that used to be inplutarch-extra) has no test coverage. This should be dealt with, either with or without more broad test revisions.plutarch-extraneeds to be subsumed into Plutarch itself, and the entire sublibrary needs to be eliminated.plutarch-apiis quite lacklustre, and needs improvement. This is particularly important for stuff coming from the Plutus side (such as data types), as this is a known confusion point. Examples of its use would also help drastically.typemust be killed with fire. While efforts have been made to makeplutarch-apifree of that terrible idea, the rest of Plutarch still has rather a lot of it.