mirror of
https://github.com/AleoHQ/leo.git
synced 2024-12-22 17:11:42 +03:00
53 lines
2.3 KiB
Markdown
53 lines
2.3 KiB
Markdown
# Leo RFC 008: Built-in Declarations
|
|
|
|
## Authors
|
|
|
|
The Aleo Team.
|
|
|
|
## Status
|
|
|
|
IMPLEMENTED
|
|
|
|
## Summary
|
|
|
|
This RFC proposes a framework for making certain (top-level) declarations (e.g. type aliases) available in every Leo program without the need to write those declarations explicitly. These may be hardwired into the language or provided by standard libraries/packages; in the latter case, the libraries may be implicitly imported or required to be explicitly imported.
|
|
|
|
## Motivation
|
|
|
|
It is common for programming languages to provide predefined types, functions, etc.
|
|
that can be readily used in programs. The initial motivation for this in Leo was to have a type alias `string` for character arrays of unspecified sizes (array types of unspecified sizes and type aliases are discussed in separate RFCs), but the feature is clearly more general.
|
|
|
|
## Design
|
|
|
|
Leo supports five kinds of top-level declarations:
|
|
|
|
- Import declarations.
|
|
- Function declarations.
|
|
- Circuit type declarations.
|
|
- Global constant declarations.
|
|
- Type alias declarations. (Proposed in a separate RFC.)
|
|
|
|
Leaving import declarations aside for the moment since they are "meta" in some sense
|
|
(as they bring in names of entities declared elsewhere),
|
|
it may make sense for any of the four kinds of declarations above to have built-in instances, i.e., we could have some built-in functions, circuit types, global constants, and type aliases. These features are why this RFC talks of built-in declarations, more broadly than just built-in type aliases that inspired it.
|
|
|
|
The built-in status of the envisioned declarations will be done through explicitly declared standard library(stdlib) files. Then these stdlib files must expressly be imported, except the files found in stdlib/prelude/*. The ones found in the prelude are features determined to be helpful enough in standard programs and are auto-imported.
|
|
|
|
## Drawbacks
|
|
|
|
This does not seem to bring any drawbacks.
|
|
|
|
## Effect on Ecosystem
|
|
|
|
This change may interact with libraries and packages in some way.
|
|
But it should not be much different from standard libraries/packages.
|
|
|
|
## Alternatives
|
|
|
|
Some alternative approaches are:
|
|
|
|
1. Having all stdlib imports auto included.
|
|
2. Require that all stdlib imports are explicitly imported.
|
|
|
|
The differences between the two above approaches and the chosen one are just how many imports are imported explicitly.
|