Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ABI support #41

Closed
aorumbayev opened this issue Jan 14, 2023 · 8 comments
Closed

ABI support #41

aorumbayev opened this issue Jan 14, 2023 · 8 comments

Comments

@aorumbayev
Copy link
Contributor

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
Copy link
Contributor Author

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
Copy link

cusma commented Jan 14, 2023

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
Copy link
Contributor Author

aorumbayev commented Jan 14, 2023

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
Copy link

cusma commented Jan 14, 2023

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
Copy link
Contributor Author

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

@barnjamin
Copy link
Contributor

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
Copy link
Collaborator

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
Copy link
Collaborator

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.

@tinymanorg tinymanorg locked and limited conversation to collaborators Feb 3, 2023
@fergalwalsh fergalwalsh converted this issue into discussion #66 Feb 3, 2023

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants