Interfaces for .rain composition

[hardyjosh]

We need to decide on the interfaces for .rain composition, both in the crate itself and in the CLI.

Short term critical path usage looks like:

1. Within the tauri binary for:
   • a .rain string directly from an editor
   • a .rain file
2. In the ob cli for a .rain file
3. In our foundry setups

For all three use cases we want to compose not compile. So the target is always a Rainlang string, not bytes or any other struct. This is because parsing Rainlang to bytecode is handled by the onchain parser contract. It's also an open question whether this repo should even hold code related to parsing Rainlang, or whether it should be in rainlanguage/rain.interpreter.

1 and #2 will be via the crate's API. @rouzwelt can you add your proposed interface here?

3 will be via CLI - we talked about outputting either as a string directly, or into a .sol file. Not sure how that would work with pragma, but I assume other than that it would just be something like:

string constant ENTRYPOINT_NAME = "rainlang string";

[rouzwelt]

the important question is if the dotrain lib should do the compilation or not? ie just produce rainlang string from the .rain or try to deploy it in a local evm and output the result, atm it does that, ie it produces the rainlang string from .rain and then deploys it into the local evm for onchain parser to parse the rainlang and report the issues or give out the exp config result, and for that it needs the Deployer data to be able to reproduce evrything on local evm.

but if we decide it doesn't need to do that, then it would take like 20 30% off of this lib. so it is important to figure this out

[rouzwelt]

something to consider is that at some point we want to have onchain LSP, ie dotrain being able to show diagnostics from onchain parser

[hardyjosh]

Sorry to clarify - I'm not saying that this crate should never parse Rainlang. Obviously it needs to do that so the extension can report issues, like you said. But that doesn't mean the code for parsing Rainlang needs to be in this crate.

In other words, if I had some Rainlang (not dotrain) and I wanted to parse it or simulate it, I could use the rain.interpeter crate only.

We should work that out but it's not for this issue

[rouzwelt]

Sorry to clarify - I'm not saying that this crate should never parse Rainlang. Obviously it needs to do that so the extension can report issues, like you said. But that doesn't mean the code for parsing Rainlang needs to be in this crate.

well that's the point, right now the LSP errors are only dotrain errors, not rainlang errors, rainlang errors you will only get after you tried to compile the dotrain and it would be shown in the output as json.

In other words, if I had some Rainlang (not dotrain) and I wanted to parse it or simulate it, I could use the rain.interpeter crate only.

We should work that out but it's not for this issue

and that yes this is totally fair, and that's why Im asking that we should first try to resolve that question of if dotrain repo should try to compile a rainlang or not, it would determine the public API. I just tried to point out that there was a plan for onchain diagnostics at some point, if that's still the case, then this crate would need to do the rainlang onchain parsing on local evm

[thedavidmeister]

so from my perspective, the contract is always right

anything we do that doesn't match the interface is just an opportunity to get things wrong

therefore we can look at the parser interface

interface IParserV1 {
    /// Parses a Rainlang string into an evaluable expression. MUST be
    /// deterministic and MUST NOT have side effects. The only inputs are the
    /// Rainlang string and the parse meta. MAY revert if the Rainlang string
    /// is invalid. This function takes `bytes` instead of `string` to allow
    /// for definitions of "string" other than UTF-8.
    /// @param data The Rainlang bytes to parse.
    /// @return bytecode The expressions that can be evaluated.
    /// @return constants The constants that can be referenced by sources.
    function parse(bytes calldata data) external pure returns (bytes calldata bytecode, uint256[] calldata constants);
}

so dotrain has to produce bytes that fit this interface, e.g. a rainlang string

the cli can stdout a rainlang string, and then people can use standard bash to do whatever they want with the string, e.g. piping to a file, sending into templates, etc. etc.

in the case of foundry, actually we can just say to use rainix which now exists, and ffi

[hardyjosh]

So to wrap up, the requirements for right now are actually fairly simple:

• Rust interface that takes a dotrain string and an array of entrypoint names and returns a rainlang string
• CLI command that takes a dotrain file and an array of entrypoint names and writes a rainlang string to stdout, or optionally to a file

[rouzwelt]

@hardyjosh @thedavidmeister in that case the meta CAS doesnt really need to store reproducible data of a deployer and dotrain also doesnt need to deploy anything on local evm in order to compile,

atm this interface you pointed is being called internally when compiling a dotrain and the result is the constant/bytecode

[thedavidmeister]

@rouzwelt not sure what you mean by that, why wouldn't we deploy locally to avoid rpc calls?

[rouzwelt]

@rouzwelt not sure what you mean by that, why wouldn't we deploy locally to avoid rpc calls?

I mean right now when compiling a dotrain, using the dotrain cli/lib, the process is like, build rainlang from dotrain, deploy the expresionDeployer contract in local evm, deploy the raining, and if it was success, return the expConfig,

what you are now suggesting would mean these steps are not needed anymore, so as a result the meta CAS also doesnt need to hold deployer data, as it doesn now, because tehre is no need for deploying anything on local evm

[hardyjosh]

How will the extension get errors from the parser if it doesn't deploy locally?

[rouzwelt]

How will the extension get errors from the parser if it doesn't deploy locally?

it simply wont, the scope of dotrain will end by producing the rainlang string, same for extension