TODOs :: Road to β

[KtorZ]

This issue summarizes the work remaining work we foresee for the β-release of Aiken. Items are settled and some may be added as needed. But it gives a general overview.

Off-chain code generation

• Experiment with extism
  • JavaScript
  • Python
• Hook extism plugins into a framework for code-gen (parsing & processing blueprints).

Note

We will no longer be addressing this since it has proven to be a non-problem. What we are observing in practice are frameworks (e.g. translucent, bloxbean, Plutus-Tx...) providing their own support for CIP-0057 Plutus blueprints which are bespoke for the language they live in. This is better than a clunky plugin system based on a portable VM.

Language Server Protocol

• Hovering at fields of a constructor in pattern-match
• Hovering on nested elements of and and or sections
• Implement quickfixes for more warnings #842
  • ImplicitlyDiscardedResult
  • SingleWhenClause
  • SingleConstructorExpect
  • UnusedVariable
  • Utf8ByteArrayIsValidHexString

Core Improvements

• warnings contradicting error: Definitions in validator modules do not need to be public. #681
• Formatting breaks code with logical operators and code blocks #682
• Confusing error message when using spread operator #677
• Keeps suggesting use of leading underscore despite it existing  #763
• Constant reference to script hash / currency symbol #676
• More options for `--keep-traces` #730
• enable pattern-matching on Void
• Supercharge constant & rework 0-arg functions
• Internal code-gen cleanup
  • Better expect statement traces
  • AirTree statements as expressions
  • Refactor and add currying optimization to uplc shrinker #770
  • Factor out redundant parts into functions
  • Improve cost of calling unconstr_data (perhaps via callback?)
  • Remove clause guards. #886
• Code type checks but fails to build #844 (likely addressed by re-working the way we desugarize when/is matches to avoid needs for re-ordering and gaps filling).
• Add Pair type to code gen to simplify and improve using tuples #880
  • Start working on separating pairs from 2 tuples in Aiken #845
• Keep track of Data-ability requirements of functions and types. Something needs to be "Data-able" when it must fits into a Data (because for example, it is put in a List or a Tuple). Then ensure that:
  • We raise proper errors when finding a non-Data-able type being used in a context that requires Data-ability (e.g. trying to put a function in a list)
  • We raise warnings for types that are Data-able provided an implicit conversion. This is the case of String, G1Element and G2Element. These can be stored in Data by casting them to a ByteArray using the VM's builtins, and cast back into their respective types when pulled out. This comes at an extra cost, hence the warning. In general, one would want to avoid that.
• Raise Uplc primitive types to Aiken types to give concrete pattern matching abilities

Plutus V3

• Implement BLS builtins #750
• Builtin semantics update (consbytestring)
• Case & Constr
  • VM support
  • Cost models
• Bitwise primitives
• Script Context Plutus v3 stdlib#83
• Allow compiling targeting either PlutusV2 or PlutusV3 #907

Property-based testing framework

• Property-based testing framework #835
• Improve existing annotations for unit tests by:
  - [x] Leveraging the new reification capabilities to show operands as Aiken expressions (instead of raw UPLC data)
  - [x] Ensure annotations also support the and and or keywords

Command-line

• Add aiken export #843
• improve UX of the uplc command group
  • Better error message
  • Better interface for passing arguments to the transaction simulator
  • ASCII diagrams?
• (automatically) provide structured JSON outputs for commands when stdout isn't an ANSI-capable terminal #892 Have command produce a structured JSON output when redirected into a non-ANSI terminal (e.g. a file). So that we can provide a nice visual output in the terminal, but useful machine-readable data when piped into files or tools like jq. This is particularly useful for tests outputs.

Aikup

• Improve aiken packages / aiken add commands #492

QA

• Finalize Marlowe's validator in Aiken and get all Marlowe's tests to pass
• Port Plutus benchmarks from PlutusTx/Haskell to Aiken
  • clausify
  • Benchmark knights #797
  • last-piece
  • primetest
  • queens
• Ensure (i.e. write tests) that we support record-update with generics (i.e. records that hold a parameter).
• Rework creation of when clauses to avoid the need for manual re-ordering and pattern filling #887

Issues to be drafted

• Colors for test budget results

[MitchTurner]

Off-chain code generation

Is this for generating types and serialization? Very excited for that. Would appreciate Rust type :)

Also, extism seems like a wasm thing. Curious how that's related to generated types.

[KtorZ]

@MitchTurner thats exactly what it is about, generating boilerplate smart constructors and serialisation code for datum and redeemers.

Extism here is used as a decoupling mechanism. We don't want to be writing all the code generation for all languages ourselves. So we need a way for the Aiken cli to delegate part of the generation to "plugins". So that in Aiken, we handle the parsing and processing of the blueprint and we hook onto plugins for generating the actual code.
Now we thought about it and people are most likely going to want to use their own favorite languages for the job, and it will be complicated to package plugins if we simply rely on binaries. Thus the need for a portable target which is widely support across languages -> wasm.

Rust is something we'd like to have eventually and it would be a nice trial if you want to give it a try and build the Rust plug-in!

[MitchTurner]

Nice. Yeah I'd be open to help out on the Rust plugin. That's the biggest pain point with Naumachia rn, manually writing the PlutusData conversions for Rust types. It'll be great to have the types handed to you from your Aiken code 🤝