Goals
=====

- Functional usability
-- Function: Prefer function over form. LRL is meant to be a practical language.
-- Usability: Prefer easy to remember, easy to read, easy to understand (in no particular order).
-- Avoid surprises / "magic stuff" that happens behind the scenes (related to the zero-cost principle below)

- Modularity / Reusability
-- Backwards compatibility
-- Avoid exposing and depending on internals and nested dependencies
-- Secure and efficient handling of dependencies:
--- It must be easy to review them before building (ie. download everything (in one step), then review everything, then build)
--- It must be possible to build a package using locally installed packages (if recent enough)
--- It must be possible to depend on modules that in turn depend on different versions of the same module
---- If versions are backwards compatible (should be except for major versions), just take the latest version.
---- If not, and if the nested dependcy isn't exposed in the modules (e.g. in APIs), then we can use both versions at the same time
---- Otherwise, it becomes tricky or impossible.
-- Existing C (etc.) code should be possible to use (but can require an LRL interface/header file).

- Lightweight / Low resource
-- For low-end systems, but also:
-- For embedded
-- For virtual machines / containers
-- For fast and parallel continuous integration
-- To encourage new-comers (1+ hour build time is discouraging)
-- To encourage new-comers (getting new hardware for building something is discouraging)
-- Zero-cost principle for unused features