Skip to content
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

Add PlutusTx version #12

Open
Tracked by #3
zmrocze opened this issue Mar 29, 2023 · 1 comment
Open
Tracked by #3

Add PlutusTx version #12

zmrocze opened this issue Mar 29, 2023 · 1 comment

Comments

@zmrocze
Copy link
Contributor

zmrocze commented Mar 29, 2023

Let's add the PlutusTx version, without changing the onchain flake, inside the same haskell onchain project.
Plutus is available there, with compile and serializeCompiledCode one can go from code to more-or-less script bytestring. Then the text envelope file - best if can be created with ply with ready library function - if not could be created ad hoc as its just a json file (with aeson).

I still think cardano-api among deps would be beneficial as its likely the first dependency a user is going to add himself, but its not indispensible.

Probably PlutusTx onchain should exactly mimic Plutarch, right? So that the two script exporters are interchangable and offchain and frontend are blind to the difference.

@zmrocze zmrocze mentioned this issue Mar 29, 2023
44 tasks
@gnumonik
Copy link
Collaborator

If we want interchangeable exporters/importers, we can either:

    1. Erase type information from the Ply output, thereby transforming it into a cardano-api style TextEnvelope (Actually we wouldn't be erasing anything, we'd just add some fields to the JSON so that ply output can be read without ply-ctl on the frontend)
    1. Implement some machinery to serialize type information when writing PlutusTx scripts such that they're compatible w/ ply-ctl

I think that today I'm going to try to implement 1) and we can discuss whether we want to put in the time to implement 2), which would probably be better but take a lot longer to implement.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants