Making TEALScript its own language

[joe-p]

Objectives

• Weigh pros and cons of maintaining native TypeScript syntax vs custom language
• Identify what the effort would be for getting tooling support (mainly IDE) for a custom language

Background

The initial goal of TEALScript was to allow developers to write native TypeScript code to write their smart contracts. It's been made clear, however, that there are some limitations when trying to adhere to TypeScript syntax. Below are some of the limitations

TypeScript Limitations

Keys must be string or number

In TypeScript, they key to an object must be a string or a number. This is the underlying reason for why storage properties must use the (key).value (previously .get(key) and .set(key, value)) interface. For example, the following code is invalid TypeScript, but would be the most intuitive way to access storage

counters = BoxMap<Account,uint64>

getCounter(): uint64 {
	return this.counters[this.txn.sender].value // Type 'Address' cannot be used as an index type. ts(2538)
}

Technically some crazy TypeScript gymnastics could be done to support doing this with an Address object, but it would still fall apart with custom object types.

No static array support

TEALScript has the custom StaticArray generic type for defining static arrays, but it can ugly real quick. It would be ideal if the following was valid syntax

type Signature = byte[64]

byte[] and strings are incompatible

In TEAL, byte[] and string are one in the same. In TEALScript, byte[] is an array and string is a string. As such, these types are fundamentally incompatible. This is why TEALScript introduces bytes, which is an alias for string that is encoded as byte[] under the hood.

Ideally the following code would be valid:

isSame(x: byte[], y: string): boolean {
	return x === y // This comparison appears to be unintentional because the types 'byte[]' and 'string' have no overlap. ts(2367)
}

Benefits of Each

TypeScript Benefits

• Out-of-the-box support for TypeScript tooling (IDEs, linters, formatters, etc.)
• All valid TEALScript is also valid TypeScript
• Don't need to spend engineering hours building and maintaining tooling

Custom benefits

• Ability to remove all of the above limitations
• Can use a custom extension which helps separate the code from regular TypeScript files
• IDEs can know exactly what will work and what won't work

Custom Language

Goals

If a custom language were to be made, I think the following goals should be achieved

IDE support (specifically VSCode)

If we go the route of a custom language, the language should be supported by popular IDEs. At the very least, it should be supported by VSCode. This means the language should have IntelliSense, highlighting, and basic formatting functionality within the IDE.

Some TypeScript Parity

When possible, TypeScript parity should be maintained. The rationale is two fold:

1. This allows TypeScript ecosystem tools, like ESLint, to ideally work with TEALScript still
2. This allows developers to copy/paste TypeScript code or use AI tools to help write TEALScript

Effort

I am personally not very familiar with what the engineering effort would be like for things like IDE support. I think the best approach would be forking the TypeScript tmLanguage repo (which would give us language support in various IDEs, including VSCode), but there may be better ways.