A macro-based approach

[eyelash]

I wonder whether you have considered building the Aiken language as a procedural Rust macro instead of a separate language. This would allow Aiken code to be embedded into Rust similar to how Plutus Tx is embedded into Haskell. This is also how Scrypto works.

Here are some pros and cons I could see from a macro-based approach:

• Pros:
  • Aiken programs/libraries could be distributed as Rust crates through Cargo and crates.io
  • Smart contracts normally need some additional code anyway to execute the transactions. With a macro-based approach this code could live together with the smart contract and be compiled together in a single step.
  • Languages need lots of additional tools such as IDE integration, code formatters, documentation generators, testing frameworks, build systems, or package managers. Embedding a language inside an existing language means you can reuse some of those tools for free.
• Cons:
  • Maybe formal verification would be more difficult?
  • A strong separation between on-chain and off-chain code could be beneficial.
  • For more complicated smart contracts a macro-based approach probably makes things like debugging more difficult.

I would be interested in your thoughts, whether there are other pros and cons, and whether it would make sense to maybe offer a procedural macro alongside the separate language down the line.

[MitchTurner]

allow Aiken code to be embedded into Rust similar to how Plutus Tx is embedded into Haskell

Smart contracts normally need some additional code anyway to execute the transactions.

This is precisely the purpose of Naumachia.

I've thought about consuming the Aiken code inside of a macro. That's one option. My current plan is just to consume the Aiken source code file as part of the Rust compilation, so essentially the same thing. Would be interested in hearing your opinion on that.

Aiken programs/libraries could be distributed as Rust crates through Cargo and crates.io

Initially this is the plan, just to bootstrap off of crates.io. But something we've discussed is having our own registry of dApps compiled to Wasm. In that case, we can consume them with the trireme cli package manager (WIP part of Naumachia), or inside of web UIs!

Another benefit is that we can generate Rust types from the Aiken code for things like Datum and Redeemer.

If you're interested in helping out, I'm looking for more contributors/critics.

[eyelash]

If you're interested in helping out, I'm looking for more contributors/critics.

I would love to get more involved in the Cardano smart contract languages space but for now I have so many other projects that it's hard to find the time beside a day job to also dive deep into Plutus. For now I'm just curiously watching the space and I'm positively surprised by how many project there are that are trying to build alternative smart contract languages.

[rvcas]

Yes, this is the better way. everything for aiken will be available as crates. Inside of a build.rs file one could import aiken::Project and provide the path to the project then everything will work just as if you were using the CLI. The plan is to have a binding/type gen flow. So in this case we'd generate consumable Rust types and Tx building functions as part of the aiken compilation process. We can then support TS, go, etc.

[rvcas]

If aiken were to live only as a rust macro we would never get good error messages, formatting, and autocomplete. Cardano deserves a full blown language for smart contracts. Plutus-Tx isn't necessarily a loved experience and I do not wish to follow in their foot steps. The idea is to expose aiken Project building as a crate in addition to the main CLI. Now that being said, it would be neat to have a macro for writing inline Untyped Plutus Core.

[KtorZ]

I think this particular argument should not be overlooked:

A strong separation between on-chain and off-chain code could be beneficial.

From my past experience, trying to blur the separation line between two domains that have vastly different constraints never works quite well. The prime example being JavaScript / Node.js. In general, backend code ends up having completely different needs and constraints than the frontend code, and they also end up being developed by different teams.

Having a clearer frontier with clear declared interfaces make it a lot easier to deal with a system at scale.

Plus, when embedding a language into another, there are many assumptions that one can't make anymore regarding the embedded language. It becomes harder to write specialized tools and optimizations specifically for that domain. We observe this with Plutus-Tx which is NOT Haskell. Very little from the Haskell ecosystem can be reused in Plutus-Tx; the framework had to redefine a set of standard libraries, and the execution VM has very different assumptions than GHC's runtime. Plus, there are features of the languages which aren't available like higher-kinded types, ad-hoc polymorphism or even just, pattern-matching on some types (such as integer).

Thus in practice, we treat on-chain Haskell and off-chain Haskell as two different languages and separate the code -- with a not so clear separation line unfortunately. More, because of:

(a) the type-system in (real) Haskell is more expressive than the subset we've access to in Plutus-Tx and;
(b) the highly restrictive constraints on-chain (such as memory budget)

We are forced to cut some corners in the modelling of on-chain types which often ends up being simply ByteString and list of ByteStrings without much more effort put in the representation of complex data-types.

Hence why, I strongly believe that there needs to be a dedicated, separate, language where the assumptions that the compiler and tools make can be specifically stated in the context for which the language was designed: on-chain execution. On top of that, it should be possible to define bridges, code generators, macros etc.. to help interoperability with other languages but -- I wouldn't make it a "killer argument" for not writing a dedicated language.

[rvcas]

well said, this is exactly where my sentiment lies as well.

[eyelash]

One other example that might be interesting to look at is SQL. While SQL can be written in separate files, it can also be embedded in other languages. I would argue that the way SQL is used to access a database is similar to how smart contracts are used to access a blockchain.

There are two main ways to embed SQL in another language: as a string or through a language-native API (for example jOOQ or Exposed). The latter approach seems to be similar to what plu-ts is doing. When SQL is embedded as an API the IDE integration already works out of the box and for the string case there are IDEs out there with good integration: syntax highlighting, auto-complete, and so on.

One major advantage of embedded SQL is that you can easily parameterize/customize the script depending on data from your main application. In theory you could also check the correctness and whether the types of the script match the types of the application at compile time but many frameworks don't do that. I wonder how parameterization will work for Aiken when code is written in separate files.

There is also the risk of SQL injection attacks which Aiken would need to handle as well, if there was some way to embed Aiken as a string into another language.

For SQL, from what I have seen so far, people tend to use embedded scripts when scripts are small and when there are many scripts and separate files for bigger scripts.

Generally I agree with the arguments so far for keeping Aiken a separate language but I still think that having an additional way to embed Aiken (maybe for small or heavily parameterized scripts) might make sense in the future. Maybe as a separate project that builds on top of the API that Aiken exposes.

[KtorZ]

I am not sure to understand how SQL is embedded in other languages? Do you mean, as eDSL?

[eyelash]

For example like this (as a string) or like this or like this (DSL). My point is that both approaches could also be used to embed Aiken into another language for specific use cases.