Cannot parse textual pir

[phadej]

E.g. when trying to parse future.pir (in the plutus-use-cases/test/Spec), I get the following error:

  pir/future.pir: pir/future.pir:204:10:
    |
204 |         (datatypebind
    |          ^^^^^^^
unexpected "datatyp"
expecting "abs", "builtin", "con", "error", "iwrap", "lam", "let", or "unwrap"

[kk-hainq]

I think overall the pretty-printer and parser are not complete and production-ready as mentioned in #3445. We have a customized parser for PLC but not PIR. And I guess the recommended way, for now, is to deserialize the binary representation.

[phadej]

Is there a variant of goldenPir which produces binary representation?

[kk-hainq]

I think setting this flag is a quick way anywhere:

{-# OPTIONS_GHC -fplugin-opt PlutusTx.Plugin:dump-pir #-}

[phadej]

{-# OPTIONS_GHC -fplugin-opt PlutusTx.Plugin:dump-pir-flat #-}

That is not the same as goldenPir, won;t make tests fail.

[kk-hainq]

Yeah, I don't think there is any. Maybe you could break the test with the pretty-printed version, then find the corresponding binary to read the AST...

[ak3n]

Is there a variant of goldenPir which produces binary representation?

Unfortunately there is no a version for binary. There are functions that read or dump flat data so it should be possible to write a goldenFlat for that purposes.

I'm closing this issue because of #3445 if you don't mind. Feel free to reopen.

[phadej]

I mind. The #3445 is about producing well-typed Core. This issue is about that even well-typed PIR won't be parsed. I.e. I cannot write PIR by hand and parse it in (I don't need that, but someone might).

[ak3n]

Oh, I should have linked or quoted it properly. As @michaelpj states

We should note that the pretty-printer and parser are 100% not intended for production use. You should use one of the binary formats if you care about that.

As I understand users shouldn't rely on them anyway. #3445 is open because it linked to the internal issue tracker.

@michaelpj could you please comment?

[michaelpj]

I'm happy to leave this open. You're all right:

• It is bad that the PIR parser and prettyprinter are not up-to-scratch. I would like us to fix this, but it's not a top priority, because...
• The textual parsers are not in (our) production pathway and won't ever be. We use them only for testing, and we recommend you similarly don't rely on them for anything else.
• The issue here arises from trying to do testing, which is indeed what we use the parser for, and it is indeed pretty annoying that it doesn't work.

So I think this is a legit bug that hopefully we will fix in due course.

[effectfully]

@thealmarty you implemented parsing of datatypebind and other PIR things, right? If so, please close this issue.

[thealmarty]

After PR #4349 and a few follow up PRs more PIR things (including datatypebind) can theoretically be parsed. However no tests were added. It was not considered to be high priority at the time. I think it's best to close this after tests are added?

[effectfully]

@thealmarty thank you.

I think it's best to close this after tests are added?

Good point, let's do that.

[effectfully]

@thealmarty do you happen to know the status of this issue?

[thealmarty]

There are tests that contain "datatypebind" in our codebase now. (Maybe there were before too, but I've recently added more for sure) E.g., here. This may be good to close?

[effectfully]

Seems like it then! Thanks a lot, closing as resolved.