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
109
110
111
112
113
114
115
116
117
118
|
# FWD
`fwd` is a toy language where the idea is that functions/procedures can never
return values, instead all computation happens "forward" by heavily utilizing
closures.
## Why?
Informally: Objects have a lot of context to keep track of, are all references
valid, who owns what, etc. and there have been lots of approaches to control
this complexity. This is yet another experiment, based on the idea that we could
syntactically specify which scope an object is valid in.
Effectively, imagine that instead of being handed an object and a bunch of rules
about how you're allowed to use it, you just specify what code to run and let
some implementer ensure that the context is safe for it.
Eventually I should probably write a better explanation, but this is good enough
for now.
## How?
Functions don't return values, instead they take some amount of closures to
execute. One pretty central feature of `fwd` is how these closures are expressed
syntactically, namely that they can be expressed outside of the function
argument list. As an example,
```
give_me_some_object() => obj1;
insert_something(obj1) => obj2;
do_something_with(obj2);
```
`=>` can be thought of as a closure operator, and in this case the body of the
closure is the rest of the function, so
```
give_me_some_object(|obj1|{
insert_something(obj1, |obj2|{
do_something_with(obj2);
}
});
```
It's possible to specify the exact scope for a closure as well:
```
check_cond(x) => a1 {
/* cond was true */
} => a2 {
/* cond was false */
}
/* runs after check_cond, not 'within' it */
```
This 'scoping' in combination with move semantics seems like an easy way to
syntactically specify both ownership and lifetime of an object,
no need for lifetime annotations or extra stuff like that.
At least hopefully, this is still a very rough idea and I wouldn't be surprised
if I have an excessively optimistic view of this. Will have to play around with
the compiler as I develop it. Presumably I'll also want references, but they are
as of yet unimplemented.
## Examples
See `examples/`. Currently there's just `uniq.fwd`, which filters out non-unique
lines from its `stdin`.
## Current state
The 'meat' of the project is still unimplemented, that being proper move semantics.
There's an initial parser and a small generator for C++ so that I can quickly
get up and running and test out programs. There's also `lib/fwdlib.hpp` which
acts as a bridge between C++ and `fwd`, and any functions that start with `fwd_`
are actually just C++ functions. This way I can start experimenting with the
language even in a very crude state, and I don't have to implement containers or
generics myself. At the moment I also kick pretty much all type checking to C++,
eventually I'd probably like to take care of it at a higher level.
## Future
If (big if) this experiment turns out to be useful on some level I'll probably
slowly try to make it more self-reliant. My target would be systems programming,
possibly even embedded systems, though I don't yet know if this 'paradigm' is
powerful enough or if I might need some escape hatches like `unsafe` in Rust.
### Really, not returns?
Semantically, yes, although it is useful to convert certain closure calls to
equivalent return statements where possible. This reduces stack usage if nothing
else, and existing compilers are more used to return-oriented programming so it
might also be possible that the produced assembly is more efficient.
As an example, see `examples/fib.fwd`. The naive C++ currently generated
(besides not actually compiling due to template instantiation depth, heh)
converts what's usually a binary tree of successive calls into a linear sequence
that takes up a huge amount of stack memory. However, we can note that a closure
call is equivalent to a return when
1. the function has only one closure parameter
2. all code paths end in the closure call
3. the closure call does not reference any local variables by reference
(except references that were taken as parameters)
Our fibonacci function matches all these cases, and could theoretically be
turned into a more typical return-oriented function for great benefit. Checking
these requirements should be relatively straightforward.
We could potentially loosen up these requirements, for example we could allow
multiple closure parameters and just return a variant, although the caller now
has to pattern match on the result. Taking things even further, we could start
treating functions more as macros and just replace the function call with the
function body, although this has some other, more fuzzy, requirements like not
allowing recursion.
We might even want to require that a function can be turned into a 'returning'
function (being pretentious we might prefer calling it 'folding' but anyway) so
that it can be interfaced from C code, for example.
|
