Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Broken / inconsistent defaulting behaviour with PAsData and record access #570

Open
colll78 opened this issue Sep 6, 2022 · 1 comment
Labels
enhancement New feature or request

Comments

@colll78
Copy link

colll78 commented Sep 6, 2022

listOfIndices <- pletC $ pconstant [1,3,5]
txInputs           <- pletC txInfo.inputs
results <- pletC $ pmap # plam (\i -> pelemAt # i # txInputs) # listOfIndices

Couldn't match type ‘PBuiltinList PTxInInfo’ with ‘PTxInInfo’
        arising from a use of ‘plam’
    • In the second argument of ‘(#)’, namely
        ‘plam (\ i -> pelemAt # i # txInputs)’
      In the first argument of ‘(#)’, namely
        ‘pmap # plam (\ i -> pelemAt # i # txInputs)’
      In the second argument of ‘($)’, namely
        ‘pmap # plam (\ i -> pelemAt # i # txInputs)
           # listOfIndices’

From a user perspective, there are many ways to work around this issue. Namely, by adding a haskell level type annotation to txInputs like so
txInputs :: Term s (PBuiltinList PTxInInfo) <- pletC txInfo.inputs

or by explicitly matching against an element of txInputs at the plutarch level type prior to using pmap on txInputs like so,
PTxInInfo indexedInput <- pmatchC (pelemAt # someIdx # txInputs)

It can compile with the type annotations / explicit pmatching on an element, but it does not compile without it. Without the type annotations it incorrectly determines that txInput is a single PTxInInfo as opposed to a PBuiltinList with elements of type PTxInInfo.

@L-as
Copy link
Member

L-as commented Sep 6, 2022

This is the HasField instance basically breaking Haskell with incoherent instances. We should just remove the incoherent instances, since the behaviour is confusing, and less necessary now after #521

@SeungheonOh SeungheonOh added the enhancement New feature or request label Jan 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants