ARC56: Extended App Description

[joe-p]

Basically takes most of the ideas in ARC32 and reorgs it in a way that is backwards compatible with ARC4 clients. Main benefit of this is HLLs can simply generate one JSON artifact.

[robdmoore]

I know the eventual goal is to use simulate, but I wonder if we add in optional per-method hints for things like:

• Fees
• Boxes
• Foreign arrays (? where you don't want that in the method selector)

And also:

• Template variables?

Are there other things that have come up in the past worth considering while we are looking at this?

[joe-p]

I know the eventual goal is to use simulate, but I wonder if we add in optional per-method hints for things like:

Fees
Boxes
Foreign arrays (? where you don't want that in the method selector)

My rationale for not including a field for these sort of things is that they can be dynamic which can be hard to describe in JSON and they could be network dependent. It also is not easy for a HLL to autogenerate these sorts of things and if the dev is required to manually write them out might as well just have them write a standardized readonly method that returns this information so they have the full power of the language and contract state/methods at their disposal (see ARC51).

Template variables?

Yes good call.

[joe-p]

@daniel-makerx @robdmoore In 35a19b3 I added ProgramSourceInfo interface that includes a pcOffsetMethod key.

I think it would be good to have an optional tealOffset key if the pcOffset is cBlock to avoid the extra byte code lookup, but it's not a hill I'd die on so comfortable if we don't have it.

Depending on consistency in decompiled output makes me a bit nervous. I think it's unlikely to change but I also think it's relatively easy to parse the cblocks if they are at the top of the program.

[daniel-makerx]

I assume name is meant to be a variable name?

Wondering if this should be an array with an optional name (and maybe description?) as scratch slots might be used without an associated name? Or perhaps the key should be the slot number since that is required and unique?

Additionally I also assume this is just for documenting scratch variables intended to be read by other applications, not necessarily every scratch slot used?

[joe-p]

Additionally I also assume this is just for documenting scratch variables intended to be read by other applications, not necessarily every scratch slot used?

Yeah exactly. The main purpose of having this field is so other contracts can easily access scratch variables. For example, TEALScript compiler uses scratch but this is only populated by user-defined scratch slots. I think forcing a name to be defined is fine because that's how it would be defined in the HLL. You can't have a property that is just a number so a name needs to be defined. I definitely like adding a desc though

[daniel-makerx]

Minor thing, noticed both StructField and this mapping don't have any sort of desc property, might be useful to have?

[joe-p]

In 19c6269 I removed teal from SourceInfo because we agreed it was only useful for developers reading the file. I realized, however, that the TEAL line numbers are also used to give better error messages even without an explicit error message, so I've added it back as an optional field RECOMMENDED for development, along with a source string