From 8459bebceb9533948193774371cbd9fd571b78ea Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Lo=C3=AFc=20Hoguin?= Date: Wed, 16 Oct 2019 09:48:31 +0200 Subject: Cowboy 2.7.0 --- articles/xerl-0.1-empty-modules/index.html | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) (limited to 'articles/xerl-0.1-empty-modules') diff --git a/articles/xerl-0.1-empty-modules/index.html b/articles/xerl-0.1-empty-modules/index.html index 0bfb60cf..03da2930 100644 --- a/articles/xerl-0.1-empty-modules/index.html +++ b/articles/xerl-0.1-empty-modules/index.html @@ -74,7 +74,7 @@

We are just starting, so let's no go ahead of ourselves here. We'll begin with writing the code allowing us to compile an empty module.

We will compile to Core Erlang: this is one of the many intermediate step your Erlang code compiles to before it becomes BEAM machine code. Core Erlang is a very neat language for machine generated code, and we will learn many things about it.

Today we will only focus on compiling the following code:

-
@@ -86,7 +86,7 @@ http://www.gnu.org/software/src-highlite -->

We will use leex for the lexer. This lexer uses .xrl files which are then compiled to .erl files that you can then compile to BEAM. The file is divided in three parts: definitions, rules and Erlang code. Definitions and Erlang code are obvious; rules are what concerns us.

We only need two things: atoms and whitespaces. Atoms are a lowercase letter followed by any letter, number, _ or @. Whitespace is either a space, an horizontal tab, \r or \n. There exists other kinds of whitespaces but we simply do not allow them in the Xerl language.

Rules consist of a regular expression followed by Erlang code. The latter must return a token representation or the atom skip_token.

-
@@ -101,7 +101,7 @@ http://www.gnu.org/software/src-highlite -->

The first rule matches an atom, which is converted to either a special representation for reserved words, or an atom tuple. The TokenChars variable represents the match as a string, and the TokenLine variable contains the line number. View the complete file.

We obtain the following result from the lexer:

-
@@ -109,7 +109,7 @@ http://www.gnu.org/software/src-highlite -->

The second step is to parse this list of tokens to add semantic meaning and generate what is called an abstract syntax tree. We will be using the yecc parser generator for this. This time it will take .yrl files but the process is the same as before. The file is a little more complex than for the lexer, we need to define at the very least terminals, nonterminals and root symbols, the grammar itself, and optionally some Erlang code.

To compile our module, we need a few things. First, everything is an expression. We thus need list of expressions and individual expressions. We will support a single expression for now, the mod expression which defines a module. And that's it! We end up with the following grammar:

-
@@ -123,7 +123,7 @@ http://www.gnu.org/software/src-highlite -->

View the complete file.

We obtain the following result from the parser:

-
@@ -135,7 +135,7 @@ http://www.gnu.org/software/src-highlite -->

There's one important thing to do when generating Core Erlang AST for a module: create the module_info/{0,1} functions. Indeed, these are added to Erlang before it becomes Core Erlang, and so we need to replicate this ourselves. Do not be concerned however, as this only takes a few lines of extra code.

As you can see by looking at the complete file, the code generator echoes the grammar we defined in the parser, and simply applies the appropriate Core Erlang functions for each expressions.

We obtain the following pretty-printed Core Erlang generated code:

-
@@ -169,6 +169,10 @@ http://www.gnu.org/software/src-highlite --> +
  • Cowboy 2.7
    • + + +
  • Gun 2.0 pre-release 1
    • -- cgit v1.2.3