Make ABI types fully specified

[jasonpaulos]

Problem

Currently the ABI types Tuple and StaticArray are not fully specified from only their type signature. Tuple has no generic arguments, and StaticArray lacks a generic argument for length. This causes a problem when used to define a subroutine that accepts these types, since the exact types the subroutine should accept is underspecified. For example:

def mySubroutine(a: abi.Tuple, b: abi.StaticArray[abi.Uint64]):
    pass

Solution

The solution is to make all type-level arguments "generic" arguments, like so:

from typing import Literal

def mySubroutine(a: abi.Tuple2[abi.Uint8, abi.Uint64], b: abi.StaticArray[abi.Uint64, Literal[10]]):
    pass

In order to support this usage, the TypeSpec class and subclasses were introduced. These classes are responsible for containing the information necessary to instantiate a type, such as the value types of a tuple.

Related to this change, many methods that were defined on Type (refactored to BaseType in this PR) have been changed to methods on TypeSpec to emphasize that they don't depend on a specific value of an ABI type.

This PR also introduces, but does not use, the function type_spec_from_annotation, which can transform an annotation like abi.StaticArray[abi.Uint64, Literal[10]] into the corresponding TypeSpec object, which in this case would be abi.StaticArrayTypeSpec(abi.Uint64TypeSpec(), 10).

A note about Tuples

Until Python 3.11 is released with support for PEP 646 -- Variadic Generics, it's not possible to parameterize abi.Tuple with an arbitrary number of generic types. As a workaround, I've created the subclasses abi.Tuple0, abi.Tuple1, ..., abi.Tuple5 which take a fixed number of generic parameters. These should be used instead of the base abi.Tuple class when you need to fully specify a tuple in a type annotation.

It could make sense to add more classes like this to support larger tuples, but I thought 5 was enough for now.

Progress

• Implementation
  • Type
  • Tuple
  • Uint types
  • Bool
  • StaticArray
  • DynamicArray
• Tests
  • Fix existing tests
  • Satisfy mypy
  • Consider new tests & replace assertions in code

[ahangsu]

Waiting on array implementations, largely looks good by now

[ahangsu]

Array part looks largely good to me

[ahangsu]

minor: I would like to propose length renamed as elem_num or array_length for readability...

[jasonpaulos]

Since this is an array I think length makes the most sense, but I'm open to other ideas. For context, this is how I imagine it would be used:

myArray = abi.DynamicArray[abi.Uint64](abi.Uint64TypeSpec())

i = ScratchVar(TealType.uint64)
program = Seq(
    myArray.decode(Txn.application_args[1]),
    For(i.store(Int(0)), i.load() < myArray.length(), i.store(i.load() + Int(1))).Do(
        myArray[i.load()].use(lambda value: Assert(value.get() == Int(7)))
    ),
    Approve(),
)

[ahangsu]

I am fine with the proposed syntax, just one funny thing noticed on first line: seems we still need to pass typespec for array argument in initialization. We should probably keep in mind to optimize that later (if possible)

[michaeldiamant]

@jasonpaulos Thanks for the effort here - Leaving approval with these notes:

• Understandably, the PR presents a big diff. I feel like I went as far as I reasonably could in my review. And I think usage in subsequent PRs will help us figure out subsequent modifications.
• I'm assuming we'll make a pass at PEP 8 naming conventions in feature/abi at a later date. Consequently, I did not attempt to provide convention feedback.

[ahangsu]

We can merge it in as is right now.

As we proceed in using this, we might optimize/modify them later.