We should decide what Rust-trait requirements are needed for data types that are either defined by or imported into Arc-Script. Traits which are required for all types should be derivable, otherwise it becomes tough to support structural types.
Traits
Debug - Needed for pretty printing. We could also create our own derive macro for Debug if the output of the builtin is not pretty enough.
ToString / FromString - Could be useful if we want to support string-scalar concatenation and interpolation, e.g., "1 2 " + 3 becomes "1 2 3".
Message, OneOf (Protobuf integration with prost) - Any type which can be used as an element inside a stream must implement this strait.
ToOwned, FromOwned - Reference counted structures cannot be serialized by prost. We may need therefore need to convert these structures into a owned representations before sending (e.g., replacing Rc<T> with Box<T>) and convert back to a reference counted representation when receiving. This conversion is in general needed whenever we interact with Arcon (e.g., when we write a value to a state backend).
Clone - For the sake of simplicity, we neither have Rust-style references/lifetimes in arc-script nor ownership/linear types. Variables are instead cloned whenever they are used in an expression. To make cloning cheap we can use reference counting.
If a variable is ephemeral (not stored inside a state of the state machine) it can be Rc<T>. Otherwise if the variable is persistent (stored inside a state of the state machine) it must implement Send + Sync by replacing Rc<T> with Arc<T>.
In addition, if the variable is mutable, we can use Rc<RefCell<T>> if it is ephemeral and Arc<Mutex<T>> if it is persistent. We may also consider having a trait which converts between ephemeral and persistent representations. This way we could convert variables into their ephemeral representation while transitioning between states, and convert back into their persistent representation when finishing a transition.
Default - Values like scalars could have a default value (0, "", etc.) which could be useful if we want to support expressions like "give me a value or its default".
Eq / PartialEq / Ord / PartialOrd - Scalars should be comparable. We may also consider making all types comparable.
We should decide what Rust-trait requirements are needed for data types that are either defined by or imported into Arc-Script. Traits which are required for all types should be derivable, otherwise it becomes tough to support structural types.
Traits
Debug- Needed for pretty printing. We could also create our own derive macro forDebugif the output of the builtin is not pretty enough.ToString/FromString- Could be useful if we want to support string-scalar concatenation and interpolation, e.g.,"1 2 " + 3becomes"1 2 3".Message,OneOf(Protobuf integration withprost) - Any type which can be used as an element inside a stream must implement this strait.ToOwned,FromOwned- Reference counted structures cannot be serialized byprost. We may need therefore need to convert these structures into a owned representations before sending (e.g., replacingRc<T>withBox<T>) and convert back to a reference counted representation when receiving. This conversion is in general needed whenever we interact with Arcon (e.g., when we write a value to a state backend).Clone- For the sake of simplicity, we neither have Rust-style references/lifetimes in arc-script nor ownership/linear types. Variables are instead cloned whenever they are used in an expression. To make cloning cheap we can use reference counting.Rc<T>. Otherwise if the variable is persistent (stored inside a state of the state machine) it must implementSend+Syncby replacingRc<T>withArc<T>.Rc<RefCell<T>>if it is ephemeral andArc<Mutex<T>>if it is persistent. We may also consider having a trait which converts between ephemeral and persistent representations. This way we could convert variables into their ephemeral representation while transitioning between states, and convert back into their persistent representation when finishing a transition.Default- Values like scalars could have a default value (0,"", etc.) which could be useful if we want to support expressions like "give me a value or its default".Eq/PartialEq/Ord/PartialOrd- Scalars should be comparable. We may also consider making all types comparable.