[Active] Sophia language and ecosystem development Q2-2023

Application Status

Status: Approved on the 04.04.2023, submitted on the 27.03.2023
Last Updated: 27.03.2023
Submitted by: Gaith Hallak, [email protected]
Team: Gaith Hallak and Radosław Rowicki
Approved Budget (in h):
Used Budget (in h):
Planned Delivery:

Specify the funding category:

Open Source Development.

Application Title:

Sophia language and ecosystem development.

Applicant:

Gaith Hallak (@ghallak) and Radosław Rowicki (@radrow).

Value Application

Improvement of smart contract development on the æternity blockchain using Sophia and FATE.

Definition of Terms

  • Sophia — most commonly used smart contract language for the æternity blockchain.
  • FATE — smart contract runtime system on the æternity blockchain.
  • Compiler — translator between a high-level language (here; Sophia) to a low level language executed by a machine (here; FATE).
  • Language ecosystem — a collective term for various tools integrated to work together for software production in a given language.

Status Quo

Sophia is a well designed language and is convenient for smart contract development. Unfortunately, the means utilizing it in professional use cases lack some maturity or external functionalities, especially regarding editor support and testing. Moreover, the language still has some parts which are underdeveloped, and while it does not drastically hinder its usability, it makes it harder to adapt by programmers not familiar with it.

Sophia developers are encouraged to use aestudio for smart contract development. While the editor is a legitimate tool, not everyone is fond of web-based editors. There is practically no alternative to it, unfortunately. While there are some extensions to VS Code, they offer little over syntax highlighting.

The REPL is a working tool and can be used for offline testing contracts. However, it lacks some features, especially regarding chain simulation and local variables. This tool is supposed to be also a contract debugger. While it supports some fundamental debugging features, those features require a lot of polishing and testing. Many quite important functionalities are missing at the moment. The HTTP interface for the REPL became highly outdated due to rapid development in recent months.

Required Work

In the long term the following should be considered:

  • Develop the debugger
    • Equip bytecode with debugging symbols
    • Make compiler emit debugging symbols
    • Make FATE consider debugging instructions by integrating them in the control flow
    • Design features and their behaviors
    • Test it thoroughly
    • Documentation
    • Tutorials
  • Develop the REPL
    • Expose an interface to all debugging features
    • Update the HTTP interface to selected REPL features
    • Cover all top-level Sophia declarations
      • Recursive functions
      • Type definitions
      • Namespaces
      • Contracts
      • Multiple definitions in a single prompt
    • Responsiveness polish
    • Testing, fix all crashes
    • Documentation
    • Tutorials
  • Develop the compiler
    • Introduce module system
    • Bug Fixing and maintenance
    • Research opportunities to allow in-browser compiling
  • Editor support
    • Language Server Protocol
    • Integrate with REPL

Our focus in this application has been marked in bold.

Estimate

I (@ghallak) will be working full time on this grant. While @radrow will be allocating time during weekends and his free time, to provide me with advice, code reviews, and might do development when required.

Known Limitations

Sophia compiler does not run in the browser, and many consider it a serious limitation.

Outlook

The points that are not marked in bold in the “Required work” section are the longer term goals that should be considered according to their priority in the future.

Publishment

We plan to publish our work in the official AE Github repositories. Project releases will be made by the end of this grant period. Some major changes or critical updates might require publishing new releases for certain projects before the end of the grant period.

Maintenance

Maintenance and bug fixes are part of this grant, and we will be providing bug fixes and updates as necessary to the projects that are developed under this grant.

5 Likes

Dear @ghallakaeternity.chain,
your application is approved by AF. Thanks for the proposal.

2 Likes

Week 1 (Apr 5 - Apr 9)

Gaith

  • Enable the inspection of switch pattern variables.
  • Enable breakpoints on switch statements.
  • Enable breakpoints on switch guards.
  • Reviews and minor bug fixes.

Time spent: 22.6

2 Likes

Week 2 (Apr 10 - Apr 16)

Gaith

  • Allow variables inspection and breakpoints inside lambdas.

Time spent: 5.2

2 Likes

Week 3 (Apr 17 - Apr 23)

Gaith

Investigate the problem of simplifying the type checker by splitting it into multiple parts, and experiment with different ways of separating the type checker module.

Time spend: 31.02 h

2 Likes

Week 4 (Apr 24 - Apr 30)

Gaith

Split the type checker into multiple modules, with the aim of eliminating the circular dependencies between these modules.

Time spent: 43.38 h

1 Like

Week 5 (May 1 - May 7)

Gaith

Starting splitting the code analysis part from the type inference part, and create a new compiler step that would perform code analysis after type checking.

Time spent: 21.79 h

1 Like

Week 6 (May 8 - May 14)

Gaith

Improvements on the new code analysis step of the compiler, and fixing old bugs in the AST fold function.

Time spent: 26.93 h

2 Likes

Week 7 (May 15 - May 21)

Gaith

Added automated tests to the FATE debugger.

Time spent: 29.08 h

1 Like

Week 8 (May 22 - May 28)

Gaith

More testing and bug fixes of the FATE debugger.

1 Like