ABI support

[aorumbayev]

Just wondering if ABI not being supported (as stated in FAQ explicitly) is something that is planned for long term (giving more 'flexibility' in some sense) so people deal with abi compliant methods themselves or its just that tealish was developed (started development) before ABI was introduced?

Would be an icing completing the cake if it gets added to tealish as well ;)

[aorumbayev]

Would also suggest enabling github discussions on a repo - perhaps as number of contributors grow - release discussions or iterating on plans for new feature might get handy when those threads are within the repo

[cusma]

My 2 cents:

I think ABI support would be great addition, at the same time Tealish seems to be a TEAL abstraction very close to the AVM, so I think supports to standards/typing/etc. that are "ARC-specs" (like the ABI) and not strictly "AVM-specs" should live into a Tealish package companion to save Tealish "pure" design guideline.

[aorumbayev]

My 2 cents:

I think ABI support would be great addition, at the same time Tealish seems to be a TEAL abstraction very close to the AVM, so I think supports to standards/typing/etc. that are "ARC-specs" (like the ABI) and not strictly "AVM-specs" should live into a Tealish package companion to save Tealish "pure" design guideline.

I see, yeah it makes sense from that standpoint - I suppose in this case some sort of addon or a plugin system complementary to tealish could be handy

[cusma]

Right. Since Tealish relies on TEAL language-specs to continuously stay up to date with AVM specs, I think this is a well defined and self-consistent language abstraction domain. Adds-on / plugins would be more suitable, in my opinion, to support ARC-specs.

[aorumbayev]

how about something like this as a separate repo @fergalwalsh ? 😄

[barnjamin]

https://github.com/barnjamin/tealish/blob/abi-types/tealish/abi.py started writing up some thoughts on how this might look?

I like the idea of making it super simple and for the only API provided for ABI types is to encode/decode, keeping the runtime confined to just int/bytes base types rather than trying to add the ABI types as some runtime supported concept.

[fergalwalsh]

Great discussion here so far. I'm still working out my own thoughts on how the ARC4 ABI should be supported in Tealish. It's my priority at the moment so hopefully will share some detailed ideas on it pretty soon.

I definitely want it to be at least possible to use method in Tealish so developers can at least have the same functionality in Tealish as Teal. @barnjamin has put some work into the AMV langspec to include pseudoops so that will be easy. I also like the idea of the abi_decode method he proposed.

I also agree with @barnjamin on keeping the runtime confined to just int/bytes base types rather than trying to add the ABI types as some runtime supported concept. Trying to figure where exactly to deal with the serialization is the tricky part though. And I'm still unsure if ABI types should be supported in structs.

I also am inclined to agree with @cusma about the scope of Tealish and the AVM spec vs ARC specs. I think it is quite probable that the current ABI spec will evolve over time and I don't think the language should be tied to the way it currently is spec'd in ARC4. So we need to consider how modules or namespaces would work in Tealish. Possibly we'd have something like from arc4 import abi_decode.
I wouldn't necessarily be opposed to an arc4 module being builtin/included in Tealish though.

Eventually we'll likely want to support external/user modules but I don't want to go down that road yet till we see real need for it. I love the ARCish photoshop work @aorumbayev :) I think we will want a plugin manager at some point but lets wait and see on this. I'd much rather copy-paste til it hurts rather than end up with an NPM-like situation. I want to see more real world use of Tealish and Algorand contracts in general before we think about these kinds of tools.

And finally, I want to see more real world use cases of the ARC4 ABI before we make firm decisions language level features specifically for it. I wonder how much of the spec developers actually use and want to use. Can we collect some examples here of Teal/PyTeal contracts in the wild using the ABI (but not dev-rel examples :) )?

[fergalwalsh]

PR #51 includes some food for thought over the weekend/next week.
It's an attempt to understand what is involved in writing an ARC4 compliant contract in Tealish with the current functionality (it does rely on #50 though)

At the moment I'm thinking this is as far as I want to go in terms of supporting ARC4 within Tealish.
I have ideas for an ABI-like interface for apps that allows for an even easier way of writing than this example but it would be incompatible with ARC4 in a number of ways. I'll expand on this idea next week.