---
# System prepended metadata

title: 'NatSpec: Dynamic expressions parser'

---

# NatSpec: Dynamic expressions parser

## Radspec

### What is Radspec?

It's a parser and evaluator for natspec Dynamic Expressions.

### Abbandoned

Aragon, the initial company behind natspec abbandoned it. And also other attempts failed.

<img src="https://i.imgur.com/yeCer19.png width=300px" width="300" height="auto" />

### But there's still hope...

At DevCon we met with a team: `rosette`, they are working on a typescript RadSpec version: https://github.com/RosetteProtocol/rosette.ts/tree/main/packages/rosette-radspec

### Why it failed?
* no one really used it
* too complex
* not documented (also on the solidity documentation just a reference)
* maybe a full interpreter is not needed?

## Alternatives?

### Without Interpeter

* ligi suggests two paths:
  * *initial*: have a simple parser that simply replaces the parameters inside the ticks with no math operations, no conditionals, no eth calls.
  * *advanced*: use the EVM to parse the expressions. E.g. 
    ```solidity
    /// @notice Use a solidity function like this `custom(param)` 
    ```
    and then you can have the custom function defined in your contract.
    check also an EIP with similar idea: https://eips.ethereum.org/EIPS/eip-4430



| PROS | CONS |
| - | - |
| easy access to contract and blockchain context | increased bytecode size (might be circumvented in the future by marking a function `documentation` so it does not end up in the bytecode to be deployed but in the metadata) |
| no new thing to learn for contract authors | more difficult to write complex cases: solidity doesn't work well with strings manipulation    |
| specification very easy to define | if a new functionality is needed then implementation could be difficult |
| easy to implement for wallet developers | wallets need to include an EVM |

### With Interpeter
* marco suggests:
  * keep radspec and improve it, remove unstable functionalities. start working on it with rosette protocol
  * create a new super simple interpreter using well known and stable libraries
  * natspec.js is unsafe, but right now it is safe if ran inside Metamask's safe environment: in this case you always want to be executed with a safe javascript environment when parsing a dynamic expression. So we could have other natspec parameters to ask for permissions, like snaps do on metamask.
    ```js
    import 'ses';

    const c = new Compartment({
      a: 5
    });

    const a = c.evaluate("`Will multiply ${a} by 7 and return ${a * 7}`");

    console.log(a)
    ```

| PROS | CONS |
| - | - |
| display very complex human readable transaction | interpeters are hard to define, hard to maintain |
| increasing the functionalities would just mean adding new features in the interpeter  | specification hard to define |
| very easy to build complex cases | more vulnerable (even if exists safe solutions) |
| bytecode size doesn't change | developers need to learn a new "language" for documentation |
| backward compatible | wallet developers need to implement the interpreter in the language of their wallet or include an interpeter |

#### With an interpreter written in Solidity

* marco suggests
    * We need an simple interpreter in solidity: NatspecInterpreterContract. Each time we need to parse a dynamic expression, you just call that smart contract passing the dynamic expression and it returns your beautiful notice

| PROS | CONS |
| - | - |
| you don't have to include any weird interpreter code into your wallet | very hard to code |
| you don't have to include useless functions in your bytecode and also it's free | |
