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
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
|
LRL - Lightweight Reusable Language
===================================
Copyright © 2011-2017 Samuel Lidén Borell
This project is abandoned and superseded by the
[SLUL programming language](https://codeberg.org/samuellb/slul) project,
which has similar goals.
What's LRL?
-----------
LRL is not at all finished yet, but it's goals are:
* **Compatibility**
* To be *fully* binary compatible with C. Regardless of whether you use it
for applications, libraries or kernels. Or if you use the foreign function
interface of some higher-level language like Python.
* This means no *global* GC, but instead safe manual memory management
with type qualifiers. And no dynamic features of course, such as lambdas.
* **Safety**
* To be somewhat memory and thread safe, and where possible detect errors at
compile time.
* Some level of "logic" safety might be offered in the future. For example,
detection of uninitialized and invalid values (such as <code>NaN</code>) at
runtime, where this can't be verified at compile-time. Possibly, LRL might
have constraints as well if it's not too hard to do.
* Foreign functions can be annotated with safety features as well. Most code
already allows safe usage if used in a structured way, it's just not
annotated and checked by the programming language.
* **Modularity**
* Separation from interface and implementation, just like .c and .h files
work in C. "Implementation" includes both data structures and code.
* LRL creates namespaces and finds header files for you if you organize
them correctly.
* Allow for lazy inclusion of files and separate compilation.
* **"Lightweightness"**
* No more bloated than a C program.
* "Zero overhead principle" like in C++. Minimal initialization code and data
segment variables.
* A "reference implementation" compiler is being written in ANSI C, and it
has no dependencies on anything else. An optimizing LLVM/C++ port can be
made later.
* **Usability**
* Don't do "magic" behind the programmers back.
* Offer expressiveness where it's safe and is easy to understand for the
programmer.
* Try to make a usable language!
Some non-goals
--------------
* **Elegance.** If <code>and</code> is more usable than <code>&&</code> then
let's use <code>and</code>. Breaking flow with <code>goto</code> is no more
harmful than <code>if</code>, as long as it's used in a sane way.
* **Paradigms.** Every function doesn't have to work on an object, like in some
OO languages. Everything isn't a pure function. Etc.
Current status
--------------
* **Frontend**
* **Tokenizer** -- Almost done. No binary/octal.
* **Parser** -- Mostly done. No sizeof/offsetof, missing a lot of
floating point stuff. Type parameter syntax might change in the future
from list\[int\], to <int>list to allow \[\] to be used for array
indices without #.
* **Syntax tree** -- Mostly done, needs optimizations.
* **Type checker** -- Some checks are missing, incomplete or broken.
Especially checks related to type parameters and qualifiers. Errors
messages are not so good and are usually repeated. Some expressions
that should be allowed require extra "as"-expressions to work.
* **Module loader** -- Works, but doesn't check that header (i.e.
interface) and implementation are compatible. The current system does
not work with "make -f", since it's relative to the current directory.
It might be changed in the future.
* **Foreign-language interface**
* **C interop** -- C headers that don't use complex C features can usually
be parsed with minor modifications.
* **Backend**
* **Null backend** -- Does nothing. Only thing that's 100% implemented :D
* **C translator** -- Most features implemented in the parser and type
checker work. Certain operations on arrays, structs and optional types
doesn't work. Non-integer types doesn't work in switch statements. Etc.
* **LLVM backend** -- Not started.
Differences from other languages
--------------------------------
Don't take list this to seriously! In some approximate order of similarity:
* **[C2 Language](http://www.c2lang.org/)** - Quite similar, both improve on
the C language. C2 changes the compilation unit from object files to
packages, while LRL changes many small details e.g. syntax, type
compatibility, behavior of mixed-type integers, etc.
* **[Nimrod](http://www.nimrod-code.org/)** - LRL has similar goals, but LRL
focuses more on compatibility between modules/libraries/versions and e.g.
ABIs.
* **[Zimbu](http://www.zimbu.org/)** - LRL has similar goals, but focuses more on safety and less on OO.
* **[Rust](http://www.rust-lang.org/ "Rust Programming Language")** - LRL strives for full C compatibility, but no tasks, blocks or binding.
* **C** - LRL has/will have better safety, modules, generic types.
* **C++** - LRL is simpler, (probably?) safer but has less features. non-C features are C compatible
* **Java** - LRL is C compatible, compiled, lighter, less OO, less "enterprise-ish"
|
