mirror of
https://github.com/AleoHQ/leo.git
synced 2024-11-24 10:52:29 +03:00
[RFC] Streamline RFC author information.
This commit is contained in:
parent
a0cf3a0f58
commit
eee2db223d
@ -2,15 +2,7 @@
|
||||
|
||||
## Authors
|
||||
|
||||
- Max Bruce
|
||||
- Collin Chin
|
||||
- Alessandro Coglio
|
||||
- Eric McCarthy
|
||||
- Pratyush Mishra
|
||||
- Jon Pavlik
|
||||
- Damir Shamanaev
|
||||
- Damon Sicore
|
||||
- Howard Wu
|
||||
The Aleo Team.
|
||||
|
||||
## Status
|
||||
|
||||
|
@ -2,14 +2,7 @@
|
||||
|
||||
## Authors
|
||||
|
||||
- Max Bruce
|
||||
- Collin Chin
|
||||
- Alessandro Coglio
|
||||
- Eric McCarthy
|
||||
- Jon Pavlik
|
||||
- Damir Shamanaev
|
||||
- Damon Sicore
|
||||
- Howard Wu
|
||||
The Aleo Team.
|
||||
|
||||
## Status
|
||||
|
||||
|
@ -2,14 +2,7 @@
|
||||
|
||||
## Authors
|
||||
|
||||
- Max Bruce
|
||||
- Collin Chin
|
||||
- Alessandro Coglio
|
||||
- Eric McCarthy
|
||||
- Jon Pavlik
|
||||
- Damir Shamanaev
|
||||
- Damon Sicore
|
||||
- Howard Wu
|
||||
The Aleo Team.
|
||||
|
||||
## Status
|
||||
|
||||
@ -18,7 +11,7 @@ FINAL
|
||||
# Summary
|
||||
|
||||
This proposal aims to improve the import management system in Leo programs to
|
||||
make program environment more reproducible, predictable and compatible. To achieve
|
||||
make program environment more reproducible, predictable and compatible. To achieve
|
||||
that we suggest few changes to Leo CLI and Manifest:
|
||||
|
||||
- add a "dependencies" section to Leo Manifest and add a command to pull those dependencies;
|
||||
@ -29,19 +22,19 @@ that we suggest few changes to Leo CLI and Manifest:
|
||||
|
||||
# Motivation
|
||||
|
||||
The current design of imports does not provide any guarantees on what's stored
|
||||
in program imports and published with the program to Aleo Package Manager.
|
||||
The current design of imports does not provide any guarantees on what's stored
|
||||
in program imports and published with the program to Aleo Package Manager.
|
||||
When a dependency is "added," it is stored inside imports folder, and it is possible
|
||||
to manually edit and/or add packages in this folder.
|
||||
|
||||
Also, imports are stored under the package name which makes it impossible to import
|
||||
two different packages with the same name.
|
||||
two different packages with the same name.
|
||||
|
||||
Another important detail in the scope of this proposal is that in future Leo
|
||||
programs will have the ability to be run with different proving systems
|
||||
and curves, possibly creating incompatibility between programs written
|
||||
programs will have the ability to be run with different proving systems
|
||||
and curves, possibly creating incompatibility between programs written
|
||||
for different proving systems or curves. To make a foundation for these features,
|
||||
imports need to be managed with include/exclude lists for allowed (compatible)
|
||||
imports need to be managed with include/exclude lists for allowed (compatible)
|
||||
proving systems and curves.
|
||||
|
||||
# Design
|
||||
@ -67,7 +60,7 @@ curve = "Bls12_377"
|
||||
proving_system = "Groth16"
|
||||
```
|
||||
|
||||
These fields are meant to be used to determine whether imported program is
|
||||
These fields are meant to be used to determine whether imported program is
|
||||
compatible to the original when support for different curves and proving systems
|
||||
is added.
|
||||
|
||||
@ -88,7 +81,7 @@ version = "1.0"
|
||||
|
||||
### Parameters description
|
||||
|
||||
`name` field sets the name of the dependency in Leo code. That way we allow
|
||||
`name` field sets the name of the dependency in Leo code. That way we allow
|
||||
developer to resolve collisions in import names manually. So, for example,
|
||||
if a developer is adding `howard/silly-sudoku` package to his program, he
|
||||
might define its in-code name as `sudoku` and import it with that name:
|
||||
@ -97,13 +90,13 @@ might define its in-code name as `sudoku` and import it with that name:
|
||||
import sudoku;
|
||||
```
|
||||
|
||||
`package`, `author` and `version` are package name, package author and
|
||||
version respectively. They are already used as arguments in `leo add`
|
||||
`package`, `author` and `version` are package name, package author and
|
||||
version respectively. They are already used as arguments in `leo add`
|
||||
command, so these fields are already understood by the Leo developers.
|
||||
|
||||
## Leo CLI
|
||||
## Leo CLI
|
||||
|
||||
To support updated Manifest new command should be added to Leo CLI.
|
||||
To support updated Manifest new command should be added to Leo CLI.
|
||||
|
||||
```bash
|
||||
# pull imports
|
||||
@ -113,11 +106,11 @@ leo fetch
|
||||
## Imports Restructurization
|
||||
|
||||
One of the goals of proposed changes is to allow importing packages with the
|
||||
same name but different authors. This has to be solved not only on the
|
||||
language level but also on the level of storing program imports.
|
||||
same name but different authors. This has to be solved not only on the
|
||||
language level but also on the level of storing program imports.
|
||||
|
||||
We suggest using set of all 3 possible program identifiers for import
|
||||
folder name: `author-package@version`. Later it can be extended to
|
||||
folder name: `author-package@version`. Later it can be extended to
|
||||
include hash for version, but having the inital set already solves name
|
||||
collisions.
|
||||
|
||||
@ -140,7 +133,7 @@ leo-program
|
||||
|
||||
This change would also affect the way imports are being processed on the ASG
|
||||
level, and we'd need to add an imports map as an argument to the Leo compiler.
|
||||
The Leo Manifest's dependencies sections needs to be parsed and passed as
|
||||
The Leo Manifest's dependencies sections needs to be parsed and passed as
|
||||
a hashmap to the compiler:
|
||||
|
||||
```
|
||||
@ -184,7 +177,7 @@ The format described here allows the Leo binary to form an imports map which can
|
||||
passed to the compiler.
|
||||
|
||||
It is important to note that Leo.lock file is created only when a package has dependencies.
|
||||
For programs with no dependencies, a lock file is not required and not created.
|
||||
For programs with no dependencies, a lock file is not required and not created.
|
||||
|
||||
## Recursive Dependencies
|
||||
|
||||
@ -208,12 +201,12 @@ It also introduces the danger of having recursive dependencies, this problem is
|
||||
# Effect on Ecosystem
|
||||
|
||||
Proposed improvement provides safety inside Leo programs and should not affect
|
||||
ecosystem except for the tools which use Leo directly (such as Aleo Studio).
|
||||
ecosystem except for the tools which use Leo directly (such as Aleo Studio).
|
||||
|
||||
It is possible that some of the proposed features will open new features on Aleo PM.
|
||||
It is possible that some of the proposed features will open new features on Aleo PM.
|
||||
|
||||
# Alternatives
|
||||
|
||||
Another approach to the stated cases is to keep everything as we have now but change
|
||||
the way programs are imported and stored and make names unique. Also, current
|
||||
implementation provides some guarantees on import stablitity and consistency.
|
||||
the way programs are imported and stored and make names unique. Also, current
|
||||
implementation provides some guarantees on import stablitity and consistency.
|
||||
|
@ -2,14 +2,7 @@
|
||||
|
||||
## Authors
|
||||
|
||||
- Max Bruce
|
||||
- Collin Chin
|
||||
- Alessandro Coglio
|
||||
- Eric McCarthy
|
||||
- Jon Pavlik
|
||||
- Damir Shamanaev
|
||||
- Damon Sicore
|
||||
- Howard Wu
|
||||
The Aleo Team.
|
||||
|
||||
## Status
|
||||
|
||||
|
@ -2,14 +2,7 @@
|
||||
|
||||
## Authors
|
||||
|
||||
- Max Bruce
|
||||
- Collin Chin
|
||||
- Alessandro Coglio
|
||||
- Eric McCarthy
|
||||
- Jon Pavlik
|
||||
- Damir Shamanaev
|
||||
- Damon Sicore
|
||||
- Howard Wu
|
||||
The Aleo Team.
|
||||
|
||||
## Status
|
||||
|
||||
@ -67,7 +60,7 @@ function bubble_sort(a: [u32; 10]) -> [u32; 10] {
|
||||
Having a countdown loop in the examples above could improve readability and
|
||||
usability of the language by making it more natural to the developer.
|
||||
|
||||
However, if we imagined this example using a countdown loop, we would see that
|
||||
However, if we imagined this example using a countdown loop, we would see that
|
||||
it wouldn't be possible to count to 0; because the first bound of the range is
|
||||
inclusive and the second is exclusive, and loops ranges must use only unsigned integers.
|
||||
|
||||
@ -75,19 +68,19 @@ inclusive and the second is exclusive, and loops ranges must use only unsigned i
|
||||
// loop goes 0,1,2,3,4,5,6,7,8
|
||||
for i in 0..9 { /* ... */ }
|
||||
|
||||
// loop goes 9,8,7,6,5,4,3,2,1
|
||||
// loop goes 9,8,7,6,5,4,3,2,1
|
||||
for i in 9..0 { /* ... */ }
|
||||
```
|
||||
|
||||
Hence direct implementation of the coundown loop ranges would create asymmetry (1)
|
||||
and would not allow loops to count down to 0 (2). To implement coundown loops and
|
||||
and would not allow loops to count down to 0 (2). To implement coundown loops and
|
||||
solve these two problems we suggest adding an inclusive range bounds.
|
||||
|
||||
# Design
|
||||
|
||||
## Coundown loops
|
||||
|
||||
Countdown ranges do not need any changes to the existing syntax. However their
|
||||
Countdown ranges do not need any changes to the existing syntax. However their
|
||||
functionality needs to be implemented in the compiler.
|
||||
|
||||
```ts
|
||||
@ -96,9 +89,9 @@ for i in 5..0 {}
|
||||
|
||||
## Inclusive ranges
|
||||
|
||||
To solve loop asymmetry and to improve loop ranges in general we suggest adding
|
||||
inclusive range operator to Leo. Inclusive range would extend the second bound
|
||||
of the loop making it inclusive (instead of default - exclusive)
|
||||
To solve loop asymmetry and to improve loop ranges in general we suggest adding
|
||||
inclusive range operator to Leo. Inclusive range would extend the second bound
|
||||
of the loop making it inclusive (instead of default - exclusive)
|
||||
therefore allowing countdown loops to reach 0 value.
|
||||
|
||||
```ts
|
||||
|
@ -2,14 +2,7 @@
|
||||
|
||||
## Authors
|
||||
|
||||
- Max Bruce
|
||||
- Collin Chin
|
||||
- Alessandro Coglio
|
||||
- Eric McCarthy
|
||||
- Jon Pavlik
|
||||
- Damir Shamanaev
|
||||
- Damon Sicore
|
||||
- Howard Wu
|
||||
The Aleo Team.
|
||||
|
||||
## Status
|
||||
|
||||
|
@ -2,14 +2,7 @@
|
||||
|
||||
## Authors
|
||||
|
||||
- Max Bruce
|
||||
- Collin Chin
|
||||
- Alessandro Coglio
|
||||
- Eric McCarthy
|
||||
- Jon Pavlik
|
||||
- Damir Shamanaev
|
||||
- Damon Sicore
|
||||
- Howard Wu
|
||||
The Aleo Team.
|
||||
|
||||
## Status
|
||||
|
||||
|
@ -2,14 +2,7 @@
|
||||
|
||||
## Authors
|
||||
|
||||
- Max Bruce
|
||||
- Collin Chin
|
||||
- Alessandro Coglio
|
||||
- Eric McCarthy
|
||||
- Jon Pavlik
|
||||
- Damir Shamanaev
|
||||
- Damon Sicore
|
||||
- Howard Wu
|
||||
The Aleo Team.
|
||||
|
||||
## Status
|
||||
|
||||
|
@ -2,14 +2,7 @@
|
||||
|
||||
## Authors
|
||||
|
||||
- Max Bruce
|
||||
- Collin Chin
|
||||
- Alessandro Coglio
|
||||
- Eric McCarthy
|
||||
- Jon Pavlik
|
||||
- Damir Shamanaev
|
||||
- Damon Sicore
|
||||
- Howard Wu
|
||||
The Aleo Team.
|
||||
|
||||
## Status
|
||||
|
||||
|
@ -2,14 +2,7 @@
|
||||
|
||||
## Authors
|
||||
|
||||
- Max Bruce
|
||||
- Collin Chin
|
||||
- Alessandro Coglio
|
||||
- Eric McCarthy
|
||||
- Jon Pavlik
|
||||
- Damir Shamanaev
|
||||
- Damon Sicore
|
||||
- Howard Wu
|
||||
The Aleo Team.
|
||||
|
||||
## Status
|
||||
|
||||
|
@ -2,14 +2,7 @@
|
||||
|
||||
## Authors
|
||||
|
||||
- Max Bruce
|
||||
- Collin Chin
|
||||
- Alessandro Coglio
|
||||
- Eric McCarthy
|
||||
- Jon Pavlik
|
||||
- Damir Shamanaev
|
||||
- Damon Sicore
|
||||
- Howard Wu
|
||||
The Aleo Team.
|
||||
|
||||
## Status
|
||||
|
||||
@ -52,7 +45,7 @@ postfix-expression = primary-expression
|
||||
/ identifier function-arguments
|
||||
/ postfix-expression "." identifier function-arguments
|
||||
/ named-type "::" identifier function-arguments ; this used to be a circuit-type
|
||||
/ named-type "::" identifier ; this is new to allow static members on
|
||||
/ named-type "::" identifier ; this is new to allow static members on
|
||||
/ postfix-expression "[" expression "]"
|
||||
/ postfix-expression "[" [expression] ".." [expression] "]"
|
||||
```
|
||||
|
Loading…
Reference in New Issue
Block a user