]> git.lizzy.rs Git - uwu-lang.git/blob - README.md
Create .gitignore
[uwu-lang.git] / README.md
1 # uwulang
2 UWU (**U**ltimate p**W**ogwamming lang**U**age) is a **functional**, **interpreted**, **weakly typed** programming language written in C.
3
4 ## What this language is
5
6 - Demonstration of dlopen - 35%
7 - Demonstration of lambda - 30%
8 - Fun excercise for myself - 20%
9 - A meme - 10%
10 - Meant for actual use - 5%
11
12 It's turing complete and somewhat useable.
13
14 ## Invocation
15
16 To build:
17
18 ```
19 make
20 ```
21
22 To run:
23
24 ```
25 ./uwu <module>
26 ```
27
28 `<module>` is a path relative to the current directory.
29 Several file names are tried, the first one that exists is used:
30
31 - `<module>`
32 - `<module>.uwu`
33 - `<module>.so`
34
35 If the file name ends with `.so`, it is treated as a native module.
36
37 ## Features
38
39 Makes heavy use of a module system with relative paths.
40
41 There is support for native modules written in C (or a C ABI compatible language) that are loaded at runtime. The standard library relies on this feature.
42
43 Strictly follows lambda principle. Functions without arguments are constants. Functions can (by design) not interact with anything globally, the input is passed to the main function and the only output is the return value of the main function. _However_, global interaction (e.g. print() or read()) could theoretically be added by native modules and since the VM does not cache any results and always calls functions, even .
44
45 Arguments are always passed by value, there are no references (except references to functions). This way, all memory allocation is stack based and no garbage collector is needed.
46
47 The syntax is very minimal. Almost everything is solved via functions (no control structures, no operators). The are only integer and string literals, but complex data structures are possible with native modules and available in the standard library.
48
49 Currently there are no floating point values, but they might be added in the future (One could also add them using native modules).
50
51 ## Syntax
52
53 A module is made out of functions. Each function is made out of a name and exactly one expression, seperated by arbitrary whitespace.
54
55 ```
56 function_name expression
57
58 other_function_name
59         other_expression
60
61
62                 weird_indent_function_name
63
64         weird_indent_expression
65
66 ```
67
68 ## Platform
69
70 Does not aim to run on a platform other than Linux. Only tested on x86_64 so far, but it should work on other architectures as well.
71
72 Uses shared object files for native modules, opens them with `dlopen`, which is POSIX.1-2001.
73
74 Requires a libc that implements asprintf (asprintf is not standard, glibc and musl implement it and there are drop-in replacements)
75
76 The current implementation of the VM does not take advantage of lambda (no caching of results), but such a feature might be added in the future. I might also add a compiler for LLVM or x86_64 NASM or a JIT in the future.