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
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
|
+++
date = "2013-03-25T00:00:00+01:00"
title = "Xerl: intermediate module"
+++
Today we will start the work on the intermediate module
that will be used to run the code for the expressions found
in our file's body, replacing our interpreter.
This is what we want to have when all the work is done:
----
xerl -> tokens -> AST -> intermediate -> cerl
----
Today we will perform this work only on the atomic integer
expression however, so we will not build any module at the end.
We have a few more things to take care of before getting there.
This does mean that we completely break compilation of modules
though, so hopefully we can resolve that soon.
This intermediate representation is in the form of a module
which contains a single function: `run/0`. This function
contains all the expressions from our Xerl source file.
In the case of a Xerl source file only containing the integer
`42`, we will obtain the following module ready to
be executed:
[source,erlang]
----
-module('$xerl_intermediate').
-export([run/0]).
run() ->
42.
----
Running it will of course give us a result of `42`,
the same we had when interpreting expressions.
The resulting Core Erlang code looks like this:
[source,erlang]
----
module '$xerl_intermediate' ['run'/0]
attributes []
'run'/0 =
fun () ->
42
end
----
The nice thing about doing it like this is that other than the
definition of the intermediate module and its `run/0`
function, we can use the same code we are using for generating
the final Beam file. It may also be faster than interpreting
if you have complex modules.
Of course this here only works for the simplest cases, as you
cannot declare a module or a function inside another Erlang function.
We will need to wrap these into function calls to the Xerl compiler
that will take care of compiling them, making them available for
any subsequent expression. We will also need to pass the environment
to the `run` function to keep track of all this.
This does mean that we will have different code for compiling
`fun` and `mod` expressions when creating
the intermediate module. But the many other expressions don't need
any special care.
Right now we've used the `'$xerl_intermediate'` atom
for the intermediate module name because we only have one, but we
will need to have a more random name later on when we'll implement
modules this way.
The attentive mind will know by now that when compiling a Xerl
file containing one module, we will need to compile two intermediate
modules: one for the file body, and one for the module's body. Worry
not though, if we only detect `mod` instructions in the file
body, we can just skip this phase.
While we're at it, we'll modify our code generator to handle lists
of expressions, which didn't actually work with integer literals
before.
We're going to use Core Erlang sequences for running the many
expressions. Sequences work like `let`, except no value
is actually bound. Perfect for our case, since we don't support
binding values at this time anyway.
Sequences have an argument and a body, both being Core Erlang
expressions. The simplest way to have many expressions is to use
a simple expression for the argument and a sequence for the rest
of the expressions. When we encounter the last expression in the
list, we do not create a sequence.
The result is this very simple function:
[source,erlang]
----
comp_body([Expr]) ->
expr(Expr);
comp_body([Expr|Exprs]) ->
Arg = expr(Expr),
Body = comp_body(Exprs),
cerl:c_seq(Arg, Body).
----
In the case of our example above, a sequence will not be created,
we only have one expression. If we were to have `42, 43, 44`
in our Xerl source file, we would have a result equivalent to the
following before optimization:
[source,erlang]
----
-module('$xerl_intermediate').
-export([run/0]).
run() ->
42,
43,
44.
----
And the result is of course `44`.
The resulting Core Erlang code looks like this:
[source,erlang]
----
module '$xerl_intermediate' ['run'/0]
attributes []
'run'/0 =
fun () ->
do 42
do 43
44
end
----
Feels very lisp-y, right? Yep.
* https://github.com/extend/xerl/blob/0.5/[View the source]
|
