blob: a17d052baf81e4f6b44cea61958f8dc95afe61bc (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
|
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
|
