Implement a proper import framework

[nielstron]

Is your feature request related to a problem? Please describe. Currently only from x import * is supported, in a very hacky way, by copying the whole content of that file into the current file.

Describe the solution you'd like Eopsin should have a proper, modular import framework.

Every module should be compiled to raw uplc + type annotations. Generally the ABI would be like this:

A compiled module is a lambda function that takes a state monad and returns a statemonad with additional names defined on a global level. The type annotations describe the type of each of the added variables.

This has several benefits

• modularity: the compiler can compile an invoked module once and can reuse the result of the compilation thereafter
• ability to embed native / haskell / ... libraries: other smart contract languages can compile to modules with the given ABI and be included through this import framework. This enables the use of optimized pluto/plutarch code or to use native haskell libraries exported via Plutus. Note that this will break the main invariant.

Import statements like from _ import x, y, z are then just an evaluation of the imported module and writing the variables obtained through accessing names x, y and z into the local statemonad.

Describe alternatives you've considered Restricting this to only eopsin code means that compiler optimizations could be used to prevent evaluating the entire namespace of the included module (which might blow up the script size).

Bug bounty: 2000 ADA

[chrissiwaffler]

I think the following problem might also be solved when having a better import framework:

When using 5 files with following structure and splitting the validator logic across the files:

• main.py (import all other files)
• functionality_1.py
• functionality_2.py
• ...

the compiled .cbor file increases a lot in size: 47 kB instead of 34 kB all functionality in a single file (analyzing my personal project)

when this compiled script is attached to a transaction, it might therefore result in exceeding the maximum transaction size of 16384 B

[nielstron]

I think the issue pointed out by @chrissiwaffler should be resolved since #268 , but the main issue is still open.