Add docs on data-backed ScriptContext

[ana-pantilie]

Fixes https://github.com/IntersectMBO/plutus-private/issues/1213

[zliu41]

The documentation should follow the format of having one sentence per line.

As an initial thought, here are some things that should be mentioned - I may have more to add later.

• When extracting fields from ScriptContext (and in general all Data-encoded types), don't use field accessors, but use record patterns to extract all needed fields at the beginning (and briefly explain why).
• If your data type includes fields that are lists or maps and you want to wrap it in asData, make sure to use the Data versions of map and list.

[ana-pantilie]

don't use field accessors, but use record patterns to extract all needed fields at the beginning (and briefly explain why)

@zliu41 I'm not sure I understand why. As far as I could see, the record patterns are just syntactic sugar over the field accessor functions. I need to look at the way GHC transforms record patterns into Haskell Core again, but I never got the impression the record pattern syntax makes any difference at that level.

I assume you're not referring to the behavior you discovered with matching on pattern synonyms like ScriptContext _ _ _, that the PIR contains some tuple, right?

[zliu41]

Using field accessors leads to repetitive computation. Extracting the third field is head . tail . tail . snd . unsafeDataAsConstr. Later, extracting the fourth field involves the same computation, but one more tail. You must rely on CSE to reduce the repetition, but it is unreliable.

[zliu41]

By the way see this slack thread: https://input-output-rnd.slack.com/archives/G01EE4NQ9U0/p1728897590920289

[zliu41]

Also have a look at AsData.Budget.Spec. Currently patternMatching is most expensive, but if we either turn on CSE, or fix the non-strict variable issue that I told you the other day, then patternMatching will be the most efficient.

[zliu41]

👍