You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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{returnthis.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
typeSignature=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 {returnx===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:
This allows TypeScript ecosystem tools, like ESLint, to ideally work with TEALScript still
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.
The text was updated successfully, but these errors were encountered:
Objectives
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 anumber
. 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 storageTechnically 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 syntaxbyte[] and strings are incompatible
In TEAL,
byte[]
andstring
are one in the same. In TEALScript,byte[]
is an array andstring
is astring
. As such, these types are fundamentally incompatible. This is why TEALScript introducesbytes
, which is an alias forstring
that is encoded asbyte[]
under the hood.Ideally the following code would be valid:
Benefits of Each
TypeScript Benefits
Custom benefits
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:
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.
The text was updated successfully, but these errors were encountered: