| License | BSD-3-Clause |
|---|---|
| Safe Haskell | Safe-Inferred |
| Language | Haskell2010 |
Swarm.Language.Requirements
Description
Requirements are things that are needed in order to successfully build a robot running a certain program.
Synopsis
- data Requirement
- data Requirements = Requirements {}
- singleton :: Requirement -> Requirements
- singletonCap :: Capability -> Requirements
- singletonDev :: Text -> Requirements
- singletonInv :: Int -> Text -> Requirements
- insert :: Requirement -> Requirements -> Requirements
- type ReqCtx = Ctx Requirements
- requirements :: TDCtx -> ReqCtx -> Term -> Requirements
Requirements
The Requirement type
data Requirement Source #
A requirement is something a robot must have when it is
built. There are three types:
- A robot can require a certain Capability, which should be fulfilled
by equipping an appropriate device.
- A robot can require a specific device, which should be equipped.
- A robot can require some number of a specific entity in its inventory.
Constructors
| ReqCap Capability | Require a specific capability. This must be fulfilled by equipping an appropriate device. Requiring the same capability multiple times is the same as requiring it once. |
| ReqDev Text | Require a specific device to be equipped. Note that at this
point it is only a name, and has not been resolved to an actual
Requiring the same device multiple times is the same as requiring it once. |
| ReqInv Int Text | Require a certain number of a specific entity to be available
in the inventory. The same comments apply re: resolving the
entity name to an actual Inventory requirements are additive, that is, say, requiring 5
of entity |
Instances
The Requirements type and utility functions
data Requirements Source #
It is tempting to define Requirements = Set Requirement, but
that would be wrong, since two identical ReqInv should have
their counts added rather than simply being deduplicated.
Since we will eventually need to deal with the different types of requirements separately, it makes sense to store them separately anyway.
Constructors
| Requirements | |
Instances
singleton :: Requirement -> Requirements Source #
Create a Requirements set with a single Requirement.
singletonCap :: Capability -> Requirements Source #
For convenience, create a Requirements set with a single
Capability requirement.
singletonDev :: Text -> Requirements Source #
For convenience, create a Requirements set with a single
device requirement.
singletonInv :: Int -> Text -> Requirements Source #
For convenience, create a Requirements set with a single
inventory requirement.
insert :: Requirement -> Requirements -> Requirements Source #
type ReqCtx = Ctx Requirements Source #
A requirement context records the requirements for the definitions bound to variables.
Requirements analysis
requirements :: TDCtx -> ReqCtx -> Term -> Requirements Source #
Infer the requirements to execute/evaluate a term in a given context.
For function application and let-expressions, we assume that the argument (respectively let-bound expression) is used at least once in the body. Doing otherwise would require a much more fine-grained analysis where we differentiate between the capabilities needed to *evaluate* versus *execute* any expression (since e.g. an unused let-binding would still incur the capabilities to *evaluate* it), which does not seem worth it at all.
This is all a bit of a hack at the moment, to be honest; see #231 for a description of a more correct approach.