Provide a list of Use Cases that the software will address.
Describe how the software will interface with other software components.
TODO - sort this section out.
Marshalled to the JVM. The JVM will generate the machine code for the system to execute.
Will software be used in creating the system? If so, indicate what software (name and version), how it is to be used, and any details about how it interfaces with the software being specified.
The Storage layer uses LMDB
What is the user interface for the software? How will users interact with the software? List out all the aspects involved in making the UI better for all users that will interact or support the software.
Kyle Butt: We will need a basic command line interface which takes in a Rholang file.
Error messages -The initial release of the Interpreter will include line numbers for debugging purposes.
This will be marshalled to the JVM
Provide a description of the software system, including its functionality and matters relating to the overall system and design. Feel free to split this up into subsections, or use data flow diagrams or process flow diagrams.
See Term Normalization and Structural Equivalence.
The normalizing parser produces terms where processes in parallel have been binned according to their type (sends, receives, expressions).
Requirements for Sort:
Sorting and then normalizing requires that the normalization preserves the sorting order (just like a stable sort). Normalizing first and then sorting is provably correct.
For example if x is bound to the name @{for (z ← @Nil)
{ z!(7) } }
, and a send occurs on @{ x | 8 }
, it has to be rewritten to: @{for (z ← @Nil) { z!(7) } | 8 }
as a key in the tuplespace.
x!(7 + 5) | for (y <- x)
here y
receives the process 12, not the process 7 + 5Terms that can't reduce should print a warning and reduce to Nil. e.g. 7 + (P | Q)
Here we do not try and cause (P | Q)
to reduce to an integer first.
(See (deprecated) RSpace 0.1 Specification)
We don't currently allow references to variables not bound in the pattern:
for (x <- y) { match x with { { *y } => P } } for (x <- y) { match x with { { for (ret, @x, @y <- a) { ret!(x + y) } } => P } } |
a
.a
is free in the pattern, and may be used in P
.Version of the JVM that we will support is:
Version of LMDB for Storage Layer:
Reference: (deprecated) RSpace 0.1 Specification
Describe any design decisions and/or strategies that affect the overall organization of the system and its higher-level structures. These strategies should provide insight into the key abstractions and mechanisms used in the system architecture. Describe the reasoning employed for each decision and/or strategy (possibly referring to previously stated design goals and principles) and how any design goals or priorities were balanced or traded-off. Such decisions might concern (but are not limited to) things like the following:
Helloworld.rho →Parser → Normalizer → Creates AST Proto (Pars) → Sorter → Sorted Proto (Throws away sort trees, as they're only for normalizing)
Interpreter uses storage and normalized protos to run.
Steps that need a home:
Spatial Type check (Matcher)
Execution by JVM ← This is the interpreter
Thread queue ← This is a small part of the interpreter
Storage ← Kyle Butt This is used by the interpreter.
Henry Till - Please fill in your understanding of how storage plays a part in the system architecture. I love pictures.