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
|
a loose collection of goals and ideas for this as-yet-unnamed language. the
main goal is really just (a) to have fun, and (b) to make a c replacement that
provides the things i personally wish the language was better on.
* very small, self-contained executables
+ hello world should ideally be on the order of a couple kilobytes
+ only functions which get referenced from main (and so on recursively)
get any code generated, even for the stdlib
+ favor size over performance where reasonable
+ effectively no language runtime
* fast compilation
+ grammar must be very easy to parse
+ more important than high performance
+ more important than minor ergonomic sacrifices
+ possibly built-in hot code reloading somewhere down the line
+ in general:
- the most important thing for coding to be fun is a tight feedback loop
* explicit
+ procedures that allocate should have an arena parameter
+ no operator overloading, but builtin vector/matrix types (eventually)
* aesthetically minimalist
+ not too many keywords or features
+ no semicolons
+ no significant whitespace
+ no parentheses around conditions
+ type inference wherever possible
* more modern type system than c
+ distinction between pointers and arrays
+ slice types (ptr, len)
- strings are slices, like rust &str or c++ str_view
+ dynamic arrays (ptr, len, cap)
- manipulation of dynamic arrays is handled by normal functions
+ type-safe generics
+ parametric polymorphism (at compile time)
+ built-in types for vector and matrix math
+ scalar types have explicit bit sizes
- u8, i32, u64, f32, f64
+ bit set support!
+ type inference
- let x = y
- can do like .ENUM_NAME when expecting an enum value, even though
otherwise it's `let x = EnumType.ENUM_NAME`
+ pascal-style postfix dereference, no need for a->b or (*a).b
- possibly also auto-dereference when accessing fields
* c interop
+ c type aliases in stdlib
+ can turn off name mangling on exported identifiers
+ ability to specify different calling conventions on:
- functions imported from outside
- functions exported
* better module system than c
+ proper module import, no header files
+ types and procedures in any order
- can be thrown out if it turns out to slow down the compiler, but
finding these first allows to hand all procedures to a thread pool for
parsing and optimization
- removes the need for function prototypes, opaque structs, etc.
+ like in odin, all files in a directory are compiled together and have
the same toplevel scope; to isolate things in a package, put them in
a different directory
+ no A::B like in c++ or rust, just a normal A.B
* portable
+ should be as easy as possible (like that's saying much...) to port to new platforms
+ at minimum support amd64 and wasm
- try and make it work with windows
+ consider having a version of the compiler which uses LLVM for release builds
* useful
+ not just a toy language!
+ begin dogfooding with it as soon as that's viable
+ write a text editor, develop the compiler with that
+ eventually bootstrap into a self-hosting one, maybe
+ utility procedures in the standard library
- string manipulation: searching, splitting, comparing, etc.
- utf8 encoding & decoding
- libc bindings
- command-line argument parsing
- consistent allocator interface
- arena allocators
- memory context allocator (like c# autorelease pool)
- file i/o, can read whole thing into string easily
+ try to get _reasonable_ levels of optimization, within the constraints of
simplicity and very fast compilation
|
