search

ethereum / fe

Emerging smart contract language for the Ethereum blockchain.
https://fe-lang.org
Other
1.59k stars 179 forks source link

EthPM, Standard Libary, and Packages ... Oh My! #95

Open pipermerriam opened 3 years ago

pipermerriam commented 3 years ago

What is wrong?

One of the powerful features of Python that I've often taken for granted is the standard library.

Similarly, packaging in general is something that isn't yet present in smart contract languages, and would be a compelling feature.

How can it be fixed

EthPM exposes a few different kinds of assets.

  1. Source Files
  2. Compiled Contracts
  3. Deployed Contracts

In theory Fe can support interfacing with all of these, though the source file level is probably the most questionable since that would ultimately require dealing with negotiation of types of source files and compatibility of source files with whatever version of the compiler is being used.

We would also need to hash out what the actual syntax is for these imports. How would someone cleanly reference deployments vs contract interfaces in import statements? Exploration into this will be needed.

Source Files

Interfacing with compatible source files would simply be a matter of establishing a standard for where the Fe-lang compiler will look when attempting to import from an installed package. Nick did some work in the EthPM CLI tool for doing local installs. I don't recall if it was ever strictly specified but there is an established directory structure it uses which would probably be the appropriate starting point for mapping import statements to source files that have been installed this way.

Compiled Contracts

Fe-lang should be able to work with previously compiled assets, assuming they come with an ABI. These can be used to construct a definition of an external interface to define how we can interact with them. One might install a standard ERC20-interface package in order to import it and be able to interact with ERC20 contracts in a generic manner, without needing to embed the interface into the local code.

Deployed Contracts

This is likely the most compelling and complicated feature, since deployments are chain specific, meaning that compilation would have to be done under some sort of context for the chain it's being compiled for. In this version, you could actually import contracts that include both the interface, and the actual address that the contract is deployed to. This functionality would be the foundation for both library code (aka the standard library) and for actually importing and interacting with specific contracts.

For the Library use case, there might be a DateTimeLibrary contract out there which maybe exposes Date and DateTime types. This gives Fe-lang enough information to enforce type safety and understand the various methods that the different types expose. At compile time Fe-lang would need to either do a generic compile which leaves the resulting bytecode unlinked, or to compile against a specific chain which would link the bytecode against the address of the deployed contract.

pipermerriam commented 3 years ago

Relevant: https://www.reddit.com/r/ethereum/comments/jc660x/calling_out_solidity_devs/

g-r-a-n-t commented 3 years ago

This functionality would be the foundation for both library code (aka the standard library) and for actually importing and interacting with specific contracts.

Is the costliness of calling out to other contracts every time we use the standard library not a concern here? It was my impression that the standard library (and other libraries) would be something that is compiled in with Fe contracts.

I'm all on board with with using EthPM for contract integration and using a standard library as much as possible, but see these as two separate things: