`Dict`'s `insert` is not compatible with PlutusTx
KristianBalaj opened this issue · comments
I'd like to point out that the behaviour of PlutusTx's AssocMap insert and aiken's Dict insert is not the same.
PlutusTx's insert is inserting new items to the end of the list where aiken's insert puts them based on sorting order AFAIU.
This means that e.g. CSL is incompatible with aiken on-chain (based on this change - Emurgo/cardano-serialization-lib#573)
Indeed. Aiken maintains an invariant on-chain that the list is ordered, which matches the behavior of the Cardano ledger.
@KristianBalaj: This means that e.g. CSL is incompatible with aiken on-chain
I am not sure to understand this claim? I'd argue that this makes Aiken MORE compatible with the CSL from reading this issue.
I am not sure to understand this claim? I'd argue that this makes Aiken MORE compatible with the CSL from reading this issue.
Yes, but the behavior got changed to the unsorted version as a reaction to that issue AFAIK.
I was actually kinda confused about all this yesterday. We could just have another type called Map in stdlib that is compatible.
I was actually kinda confused about all this yesterday. We could just have another type called Map in stdlib that is compatible.
Yup, I think that would be a good solution supporting both cases.
I've given this more thought when I've implemented the Map for my needs and I've realized that it shouldn't be in the stdlib.
As I've mentioned the CSL, it doesn't already change the order of Map items when serialised/deserialised (this was changed based on the referenced issue).
That said, with such behaviour both unordered and ordered implementations of Map are supported by CSL, since it doesn't modify the order anymore and just takes and transforms what it gets.
IMO, the aiken's dict is much more effective/performant with it's invariants in most cases that an unordered version. The purpose of the unordered version would be to just make something backward compatible with PlutusTx and for new stuff build using the aiken's dict.
For that reason the unordered version has just a very specific use and shouldn't be part of the stdlib.
The only important thing is that the off-chain framework has to use the same behaviour of the dict as the on-chain.
That said, this issue can be closed if you agree.
@KristianBalaj makes sense to me, closing for now. Thanks for coming back to this.