# Solving reverse polish notation equations in WebAssembly using F#

Note: this blog post is part of the F# advent calendar 2019.

# Introduction

In this blog post, we’ll build a website that can solve Reverse Polish Notation (RPN) equations. All code (including the website) will be written in F#, but the equations themselves will be solved using WebAssembly.

# Reverse Polish Notation

In RPN equations, operators (`+`

, `-`

, etc.) follow their operands (`1`

, `3`

, etc.). This is known as postfix notation. Its main advantage: parentheses are no longer needed to define precedence. Consider the following equation (in standard mathematical notation):

```
(1 + 3) * (5 - 2)
```

This is the same equation, but specified in RPN:

```
1 3 + 5 2 - *
```

To solve this RPN equation we can just interpret its parts as a series of stack operations:

- Push
`1`

on the stack. - Push
`3`

on the stack. - Pop
`3`

from the stack. Pop`1`

from the stack. Apply the`+`

operator to the popped operands. Push`4`

on the stack. - Push
`5`

on the stack. - Push
`2`

on the stack. - Pop
`2`

from the stack. Pop`5`

from the stack. Apply the`-`

operator to the popped operands. Push`3`

on the stack. - Pop
`3`

from the stack. Pop`4`

from the stack. Apply the`*`

operator to the popped operands. Push`12`

on the stack.

As you can imagine, the code to solve RPN equations will be a lot simpler than code to solve equations in standard mathematical notation, as the latter requires one to handle operator precedence rules and nesting (parentheses).

Side note: the famous Edsger Dijkstra invented the Shunting-yard algorithm to convert from infix notation to postfix notation.

In order for our website to be able to solve RPN equations, we’ll start by building a parser. As said, all our code will be written in F#.

## Parsing

Each RPN equation is composed of:

- Operands (the integers).
- Operators (the functions).

We’ll model this as follows:

```
type Operator =
| Add
| Sub
| Mul
| Div
type Operand =
| Integer of int
type Expression =
| OperatorExpression of Operator
| OperandExpression of Operand
type Equation =
| Equation of Expression list
```

Our model allows for both empty- and invalid equations. A more advanced model would make illegal states unrepresentable, but for now we’ll keep it simple.

Not all equations will be valid though. There are three types of errors we’ll cover:

- Empty equations: no operands nor operators.
- Invalid equations: one or more unknown tokens.
- Unbalanced equations: equation does not resolve to a single operand.

We’ll model these errors as follows:

```
type EquationError =
| Empty
| Invalid of string
| Unbalanced
```

Now on to the actual parsing. First, let’s try to parse an expression (which is either an operand or an operator):

```
let parseExpression (word: string): Result<Expression, EquationError> =
match word with
| "+" -> Ok(OperatorExpression Add)
| "-" -> Ok(OperatorExpression Sub)
| "*" -> Ok(OperatorExpression Mul)
| "/" -> Ok(OperatorExpression Div)
| Int32 i -> Ok(OperandExpression(Integer i))
| _ -> Error(Invalid word)
```

This is fairly straightforward code, where we map strings to operator expressions and integers to operand expressions using a custom active pattern. Note that the return type is not an `Expression`

, but a `Result<Expression, EquationError>`

, as we also want to capture if the word we tried to parse was invalid.

Our next step is to convert a `string`

to its words (represented as a list of strings):

```
module String =
let words (str: string): string list =
str.Trim().Split([| ' ' |], StringSplitOptions.RemoveEmptyEntries)
|> List.ofArray
```

Using these two functions, we can start building the `parse`

function:

```
let parse (str: string): Result<Equation, EquationError> =
let words = String.words str
let expressions = List.map parseExpression words
...
```

The `expressions`

value has type `Result<Expression, EquationError> list`

, so it is a list of `Result`

’s. We’d like to convert it to a `Result<Expression list, EquationError>`

, as we can then convert the `Expression list`

to an `Equation`

. We can flatten the `Result list`

into a single `Result`

using this function:

```
module Result =
let ofList (results: Result<'a, 'b> list): Result<'a list, 'b> =
let folder resultState resultElement =
match resultState, resultElement with
| Ok results, Ok element -> Ok(element :: results)
| Error err, _ -> Error err
| _, Error err -> Error err
results
|> List.fold folder (Ok [])
|> Result.map List.rev
```

We are now able to create a complete, working version of our `parse`

function:

```
let parse (str: string): Result<Equation, EquationError> =
str
|> String.words
|> List.map parseExpression
|> Result.ofList
|> Result.map Equation
```

Let’s try calling our `parse`

function to test it:

```
parse "1 2 +"
val it : Result<Equation,EquationError> =
Ok
(Equation
[OperandExpression (Integer 1); OperandExpression (Integer 2);
OperatorExpression Add])
```

Hurray! Parsing works. We’re not completely done with parsing though, as we have two types of errors that we haven’t checked for: empty- and unbalanced equations. To handle these cases, we’ll add the following function:

```
let validate (expressions: Expression list): Result<Expression list, EquationError> =
let rec helper remainder stack =
match remainder, stack with
| [], [] -> Error Empty
| [], [ OperandExpression _ ] -> Ok(expressions)
| OperandExpression i :: xs, _ -> helper xs (OperandExpression i :: stack)
| OperatorExpression i :: xs, OperandExpression _ :: OperandExpression _ :: ys ->
helper xs (OperandExpression(Integer 0) :: ys)
| _ -> Error Unbalanced
helper expressions []
```

Using pattern matching and recursion, we’re walking through an `Expression list`

and check to see if it is empty or unbalanced (an operator is found but not enough operands to work with). We can insert this function into our parsing pipeline using `Result.bind`

:

```
let parse str =
str
|> String.words
|> List.map parseExpression
|> Result.ofList
|> Result.bind validate
|> Result.map Equation
```

Let’s verify that our pipeline detects these errors:

```
parse ""
val it : Result<Equation,EquationError> = Error Empty
parse "3 4 + -"
val it : Result<Equation,EquationError> = Error Unbalanced
```

Looks like it’s working!

# REPL

Before we move on to the WebAssembly part, let’s build a tiny REPL in which we can solve RPN equations. First, let’s add code to evaluate (solve) an equation:

```
type EvaluationResult =
| EvaluationResult of int
let evaluateExpression (stack: int list) (expression: Expression): int list =
match expression, stack with
| OperandExpression(Integer operand), _ -> operand :: stack
| OperatorExpression Add, x :: y :: xs -> y + x :: xs
| OperatorExpression Sub, x :: y :: xs -> y - x :: xs
| OperatorExpression Mul, x :: y :: xs -> y * x :: xs
| OperatorExpression Div, x :: y :: xs -> y / x :: xs
| _, _ -> failwith "Invalid expression"
let evaluateEquation (Equation expressions): EvaluationResult =
expressions
|> List.fold evaluateExpression []
|> List.head
|> EvaluationResult
let evaluate (str: string): Result<EvaluationResult, EquationError> =
parse str
|> Result.map evaluateEquation
```

Here you can clearly see the stack-based algorithm reflected that we mentioned in the RPN introduction.

Now all that’s left is to create a REPL loop:

```
let printInstructions(): unit =
printfn "Please enter an equation and evaluate it by pressing enter..."
let read(): unit =
Console.ReadLine()
let eval (input: string): unit =
evaluate input
let printOutcome (EvaluationResult outcome): unit =
printfn "Outcome: %A" outcome
let parserErrorMessage (error: EquationError): string =
match error with
| Empty -> "Empty equation"
| Invalid token -> sprintf "Invalid token: %s" token
| Unbalanced -> "Equation is unbalanced"
let printError (error: EquationError): unit =
let errorMessage = parserErrorMessage error
printfn "Error: %s" errorMessage
let print (result: Result<EvaluationResult, EquationError>): unit =
match result with
| Ok outcome -> printOutcome outcome
| Error error -> printError error
let loop(): unit =
while true do
read()
|> eval
|> print
[<EntryPoint>]
let main _ =
printInstructions()
loop()
0
```

Simple and elegant. Let’s try out the REPL:

```
Please enter an equation and evaluate it by pressing enter...
1 2 +
Outcome: 3
2 4 * + 7
Error: Equation is unbalanced
```

Nice. We’re ready to move on solving RPN equations using WebAssembly.

# WebAssembly

Before we dive into the details, let’s refresh our knowledge on what WebAssembly is. The official website has the following definition:

WebAssembly (abbreviated Wasm) is a binary instruction format for a stack-based virtual machine. Wasm is designed as a portable target for compilation of high-level languages like C/C++/Rust, enabling deployment on the web for client and server applications.

A great way to learn more about WebAssembly is to check out the cartoon intro to WebAssembly by Lin Clark. For now, just keep in mind that WebAssembly can be executed in the browser and that there is both a binary format (WASM) and a text format (WAT).

As said, our goal will be to have a website that can solve RPN equations. The first step is to parse the equation (using the code we just wrote). The parsed equation will then be compiled to (binary) WebAssembly code. The WebAssembly code is then executed in the browser. Finally, we’ll display the result of the solved equation as well as the WebAssembly used to solve it (binary *and* text format). Sounds fun? Let’s get to it!

## Generating WebAssembly

In principle, we could be writing F# to output a generic RPN notation solver in WebAssembly, but to keep things simple, we’ll just compile the minimal WebAssembly needed to solve a RPN equation.

The stack-based algorithm used five types of operations:

- Push a number.
- Add two numbers.
- Subtract two numbers.
- Multiply two numbers.
- Divide two numbers.

If we look at the available WebAssembly instructions, we can find direct counterparts for all these operations, which we’ll model as follows:

```
type WebAssemblyInstruction =
| I32Const of int
| I32Add
| I32Sub
| I32Mul
| I32Div
```

In our domain, we only support a single numeric type: 32-bit integers. In WebAssembly, these types are referred to as value types:

```
type WebAssemblyValueType = I32
```

For our purposes, a WebAssembly function can be modelled as a name, result type and a list of instructions:

```
type WebAssemblyFunction =
{ Name: string
Result: WebAssemblyValueType
Body: WebAssemblyInstruction list }
```

Functions in WebAssembly are always organized in a module. Our code will only ever have one function so we can make this a 1-1 mapping:

```
type WebAssemblyModule =
{ Function: WebAssemblyFunction }
```

We can now convert a parsed equation to its corresponding WebAssembly module:

```
let expressionToWebAssemblyInstruction (expression: Expression): WebAssemblyInstruction =
match expression with
| OperandExpression(Integer i) -> I32Const i
| OperatorExpression Add -> I32Add
| OperatorExpression Sub -> I32Sub
| OperatorExpression Mul -> I32Mul
| OperatorExpression Div -> I32Div
let equationToWebAssemblyCode (Equation expressions): WebAssemblyInstruction list =
List.map expressionToWebAssemblyInstruction expressions
let equationToWebAssemblyModule (equation: Equation): WebAssemblyModule =
{ Function =
{ Name = "evaluate"
Result = I32
Body = equationToWebAssemblyCode equation } }
```

In a moment, we’ll write code to convert a `WebAssemblyModule`

to WebAssembly text format (WAT) and binary format (WASM). Let’s start with defining some types for the WebAssembly output:

```
type WebAssemblyText = WebAssemblyText of string
type WebAssemblyBinary = WebAssemblyBinary of int list
type WebAssembly =
{ Text: WebAssemblyText
Binary: WebAssemblyBinary }
```

We can now define the pipeline to compile a RPN equation to WebAssembly:

```
let equationToWebAssembly (equation: Equation): WebAssembly =
let webAssemblyModule = equationToWebAssemblyModule equation
{ Text = Text.outputModule webAssemblyModule
Binary = Binary.outputModule webAssemblyModule }
let convert (str: string): Result<WebAssembly, EquationError> =
parse str
|> Result.map equationToWebAssembly
```

This code will not compile, as we haven’t yet defined the functions to convert the module to text and binary format. Let’s fix this.

### Text format

While the WebAssembly text format spec is great, Mozilla’s Understanding WebAssembly text format page was invaluable when trying to understand what the text format looks like in practice. In essence, a WebAssembly module is an s-expression, which is a recursive format designed to represent trees.

Here’s the WAT text we’d like to generate for the RPN equation: `1 2 +`

:

```
(module
(func (export "evaluate") (result i32)
i32.const 1
i32.const 2
i32.add))
```

There is not much to the WAT output we want to generate. It defines a module with one function. That function takes no parameters, has three instructions and returns an `i32`

value. Finally, the function is exported with the name “evaluate,” which will allow us to call it from JavaScript later.

The actual code to convert our WebAssembly module to its text format representation is fairly straightforward:

```
let outputValueType (valueType: WebAssemblyValueType): string =
match valueType with
| I32 -> "i32"
let outputResult (resultType: WebAssemblyValueType): string =
sprintf "(result %s)" (outputValueType resultType)
let outputInstruction (instruction: WebAssemblyInstruction): string =
match instruction with
| I32Const i -> sprintf "i32.const %i" i
| I32Add -> "i32.add"
| I32Sub -> "i32.sub"
| I32Mul -> "i32.mul"
| I32Div -> "i32.div_32"
let outputBody (instructions: WebAssemblyInstruction list): string =
instructions
|> List.map outputInstruction
|> String.concat " "
let outputExport (name: string): string =
sprintf "(export \"%s\")" name
let outputFunction (function': WebAssemblyFunction): string =
let export = outputExport function'.Name
let result = outputResult function'.Result
let body = outputBody function'.Body
sprintf "(func %s %s %s)" export result body
let outputModule (module': WebAssemblyModule): WebAssemblyText =
outputFunction module'.Function
|> sprintf "(module %s)"
|> WebAssemblyText
```

Tiny note: this code doesn’t output the code in an indented format, but it is semantically equivalent.

### Binary format

The binary format is a bit more involved than the text format. Once again, the basis is formed by a module, which is represented as a list of bytes.

The first two parts of a module are fixed, and consist of a magic header and a version:

```
let outputMagicHeader: int list = [ 0x00; 0x61; 0x73; 0x6d ]
let outputVersion: int list = [ 0x01; 0x00; 0x00; 0x00 ]
```

Note that we defined the values in hexadecimal notation to have them correspond directly to how they are defined in the spec. We could have defined them as bytes, but for the sake of code brevity we’ll use regular ints.

Let’s move on to the contents of a module, which is comprised of zero or more sections. Each section consists of:

- A one-byte section ID.
- The
`u32`

size of the contents, in bytes. - The actual contents, which depends on the type of section.

While there are (currently) 12 different types of sections, we only need four of them:

```
type Section =
| Type
| Function
| Export
| Code
```

The first part of a section, its ID, can be output as follows:

```
let outputSectionIndex (section: Section): int =
match section with
| Type -> 0x01
| Function -> 0x03
| Export -> 0x07
| Code -> 0x0a
```

The second and third part deal with the section’s contents. The second part is defined as the `u32`

size of the contents. If we examine the `u32`

spec, we can see that `u32`

values must be encoded using the LEB128 encoding. LEB128 encoding is a variable-length encoding, which means that different numbers can be encoded using a different number of bytes.

The LEB128 format has two different algorithms: one for unsigned integers and one for signed integers. Let’s start with the unsigned integers first:

```
let outputUnsignedLEB128 (i: int): int list =
let bitEightMask = 0b1000_0000
let bitsOneToSevenMask = 0b0111_1111
let mutable more = true
let mutable value = i
let mutable bytes = ResizeArray<int>()
while more do
let mutable byte = value &&& bitsOneToSevenMask
value <- value >>> 7
more <- value <> 0
if value <> 0 then byte <- byte ||| bitEightMask
bytes.Add(byte)
List.ofSeq bytes
```

Note that we used mutation here. While immutability is great, it is good to remember that not all F# code *has* to be immutable. Here, we only use mutation *inside* our function; it is an implementation detail. The actual returned value is a regular, immutable list.

The signed output is similar, but slightly different:

```
let outputSignedLEB128 (i: int): int list =
let bitEightMask = 0b1000_0000
let bitSevenMask = 0b0100_0000
let bitsOneToSevenMask = 0b0111_1111
let mutable more = true
let mutable value = i
let mutable bytes = ResizeArray<int>()
while more do
let mutable byte = value &&& bitsOneToSevenMask
value <- value >>> 7
if value = 0 && (byte &&& bitSevenMask) = 0 then more <- false
elif value = -1 && (byte &&& bitSevenMask) > 0 then more <- false
else byte <- byte ||| bitEightMask
bytes.Add(byte)
List.ofSeq bytes
```

Outputting an integer means choosing between the two LEB128 algorithms:

```
let outputInteger (i: int): int list =
if i < 0 then outputSignedLEB128 i
else outputUnsignedLEB128 i
```

As you might recall, the reason why we needed to output an integer was to output the length of the section’s code. In WebAssembly, bytes prefixed by their length are referred to as a vector:

```
let outputVector (bytes: int list): int list =
let length =
bytes
|> List.length
|> outputInteger
length @ bytes
```

Outputting a section is then a simple combination of outputting its section index and its vector:

```
let outputSection (section: Section) (bytes: int list): int list =
outputSectionIndex section @ outputVector bytes
```

Now that we have the basics defined, let’s move on to the output of the individual sections.

#### Type section

The type section encodes the function types of the functions defined in the module (of which we only have one). A function type is defined as the vector of a vector for the parameter types and a vector for the result (return) types:

```
let outputValueType (valueType: WebAssemblyValueType): int =
match valueType with
| I32 -> 0x7f
let outputResult (resultType: WebAssemblyValueType): int =
outputValueType resultType
let outputFunctionTypes (function': WebAssemblyFunction): int list =
let parametersCount = outputInteger 0x00
let resultsCount = outputInteger 0x01
let resultType = outputResult function'.Result
let functionType = 0x60
functionType :: parametersCount @ resultsCount @ [ resultType ]
let outputTypeSection (function': WebAssemblyFunction): int list =
let functionCount = outputUnsignedLEB128 0x01
let functionTypes = outputFunctionTypes function'
functionCount @ functionTypes
|> outputSection Section.Type
```

#### Function section

The function section links a function’s index to the function type. We have only one function, and thus only one function type, so we can hardcode the number of functions and the function index:

```
let outputFunctionSection: int list =
let functionsCount = outputInteger 0x01
let firstFunctionSignatureIndex = outputInteger 0x00
functionsCount @ firstFunctionSignatureIndex |> outputSection Section.Function
```

#### Export section

In the export section, everything is listed that should be exposed to the “outside world.” When running WebAssembly in the browser, this means the exported values can be accessed from JavaScript. As we want to call our RPN solving function from JavaScript, we have to export our function.

As we only have one type we want to export (our function), we can use the following code:

```
type ExportType = FunctionExport
let outputExportType (exportType: ExportType): int =
match exportType with
| FunctionExport -> 0x00
```

Next, we’ll define a function to output a string, which we’ll use in a moment to define the exported function’s name:

```
let outputString (str: string): int list =
str
|> Seq.map int
|> Seq.toList
|> outputVector
```

Finally, we can glue these things together:

```
let outputExportSection (function': WebAssemblyFunction): int list =
let exportsCount = outputInteger 0x01
let exportName = outputString function'.Name
let exportType = outputExportType FunctionExport
let exportFunctionIndex = outputInteger 0x00
exportsCount @ exportName @ [ exportType ] @ exportFunctionIndex |> outputSection Export
```

#### Code section

The final section is the code section, which contains (as you might have guessed) the code that a function will execute.

First, we’ll add a mapping from a WebAssembly instruction to its bytes:

```
let outputInstruction (instruction: WebAssemblyInstruction): int list =
match instruction with
| I32Const i -> 0x41: outputInteger i
| I32Add -> [ 0x6a ]
| I32Sub -> [ 0x6b ]
| I32Mul -> [ 0x6c ]
| I32Div -> [ 0x6e ]
```

Next, the body is defined as number of local declarations (of which we have none), the actual instructions, and finally a special marker for the end of the body:

```
let outputBody (instructions: WebAssemblyInstruction list): int list =
let localDeclarationsCount = outputInteger 0x00
let instructions = List.collect outputInstruction instructions
let bodyEnd = 0x0b
localDeclarationsCount @ instructions @ [ bodyEnd ] |> outputVector
```

The final code to output the code section is then simple:

```
let outputCodeSection (function': WebAssemblyFunction): int list =
let functionCount = outputInteger 0x01
let body = outputBody function'.Body
functionCount @ body |> outputSection Code
```

#### Output module

Outputting a module is now a case of appending the outputs of the different sections:

```
let outputModule (module': WebAssemblyModule): WebAssemblyBinary =
let typeSection = outputTypeSection module'.Function
let functionSection = outputFunctionSection
let exportSection = outputExportSection module'.Function
let codeSection = outputCodeSection module'.Function
outputMagicHeader @ outputVersion @ typeSection @ functionSection @ exportSection @ codeSection
|> WebAssemblyBinary
```

And we’re done! We can now compiling any RPN equation to its WebAssembly format. Let’s start building the website now.

## Building the website

To build the website using only F#, we can use the fabulous (pun intended) Fable compiler. Fable is a compiler that can compile F# code to JavaScript code. Precisely what we need!

Our website will use a particular flavor of Fable called Elmish. With Elmish, one can build applications using the Model-View-Update architecture that was popularized by Elm.

Our first step in building our Elmish application is to define the application’s model. In an Elmish application, the model is used as input to render the website. As such, the model should contain everything that we want to display on our website, which for our application looks like this:

```
type EvaluationResult =
{ Result: int
Wasm: int list
Wat: string }
type EvaluationError =
| WebAssemblyException of exn
| EmptyEquation
| InvalidEquation of string
| UnbalancedEquation
type Model =
{ Evaluation: Result<EvaluationResult, EvaluationError> option
Equation: string }
```

The types are relative simple. There is an evaluation result that contains the result of the evaluation, as well as the generated WASM (binary format) and WAT (text format). The evaluation result itself is an optional part of the model (there is no evaluation initially). The other part of the model is the equation to solve.

For the first render of the website, Elmish requires us to provide a function that returns the initial model:

```
let init(): Model * Cmd<'a> =
{ Evaluation = None
Equation = "" }, Cmd.none
```

Of course, we need to be able to update the model if we are to have any interactivity on our website. In the Elmish model, updating the model means sending a message. These messages are defined as a regular discriminated union:

```
type Msg =
| UpdateEquation of string
| EvaluateEquation
| EquationEvaluatedSuccessfully of Evaluation
| EquationEvaluatedWithError of EvaluationError
```

The next step is to define a function that takes a message and a model, and then returns a model and a command (we’ll get to what a command is):

```
let update (msg: Msg) (model: Model): Model * Cmd<'a> =
match msg with
| UpdateEquation newEquation ->
{ model with Equation = newEquation }, Cmd.none
| EvaluateEquation ->
evaluate model
| EquationEvaluatedSuccessfully evaluation ->
{ model with Evaluation = Some(Ok evaluation) }, Cmd.none
| EquationEvaluatedWithError error ->
{ model with Evaluation = Some(Error error) }, Cmd.none
```

The `UpdateEquation`

, `EquationEvaluatedSuccessfully`

and `EquationEvaluatedWithError`

paths are relatively straightforward. They take a message with a payload and then update the model with that payload and return the model. These paths also return `Cmd.none`

to indicate that there is no new message that needs to be processed.

The interesting path is the one where the user has requested that the equation be evaluated. The `evaluate`

function calls the `convert`

method, which takes an equation as input and returns the compiled WebAssembly:

```
let evaluate (model: Model): Model * Cmd<'a> =
match convert model.Equation with
| Ok webAssembly -> equationEvaluatedSuccessfully model webAssembly
| Error error -> equationEvaluatedWithError model error
```

In the error case, we map the `EquationError`

to an `EvaluationError`

and then return the (unchanged) model and a new message indicating that the model should be updated with the error:

```
let equationEvaluatedWithError (model: Model) (error: EvaluationError): Model * Cmd<'a> =
let evaluationError =
match error with
| Empty -> EmptyEquation
| Invalid token -> InvalidEquation token
| Unbalanced -> UnbalancedEquation
model, Cmd.ofMsg (EquationEvaluatedWithError evaluationError)
```

This code shows that instead of just updating the model and returning `Cmd.none`

, one could also choose to send a new command with a new message, deferring the actual updating of the model to the message handler.

For the success case, where an equation was successfully compiled to WebAssembly, we want to execute the WebAssembly in the browser. This means interacting with browser API’s. Many API’s have type-safe wrappers in Fable, but with the WebAssembly stuff being fairly new, we have to add those wrappers ourselves. Luckily, this is extremely easy:

```
[<AutoOpen>]
module WebAssembly =
type Instance =
{ exports: obj }
type ResultObject =
{ instance: Instance }
[<Emit("WebAssembly.instantiate($0)")>]
let instantiate (bufferSource: ArrayBuffer): JS.Promise<ResultObject> = jsNative
[<AutoOpen>]
module Uint8Array =
[<Emit("Uint8Array.from($0)")>]
let from (bytes: int list): ArrayBuffer = jsNative
```

As you can see, we define the browser API’s as regular functions, but with a special `Emit`

attribute that Fable will use when converting the F# to JavaScript.

We now have all the infrastructure we need to execute our compiled WebAssembly:

```
let equationEvaluatedSuccessfully model webAssembly =
let (WebAssemblyText(wat)) = webAssembly.Text
let (WebAssemblyBinary(wasm)) = webAssembly.Binary
let onSuccess webAssemblyInBrowser =
EquationEvaluatedSuccessfully
({ Result = webAssemblyInBrowser.instance.exports?evaluate ()
Wasm = wasm
Wat = wat })
let onError ex = EquationEvaluatedWithError(WebAssemblyException ex)
let cmd = Cmd.OfPromise.either WebAssembly.instantiate (Uint8Array.from wasm) onSuccess onError
model, cmd
```

Running our WebAssembly function is done through the interop code we just wrote: `webAssemblyInBrowser.instance.exports?evaluate()`

. The `evaluate()`

call is actually our compiled and exported WebAssembly function.

The last part of this function is instructing Fable to execute a function that returns a JavaScript promise (`WebAssembly.instantiate`

), and call one of the two passed callbacks when the promise completed successfully or with an error.

The final step in building our website is to write functions to render our UI. With Elmish, rendering HTML is not done in a regular templating language, but using plain F# functions. Consider the following function to output the evaluation output contents:

```
let equationOutputContent (resultClass: string) (text: string): ReactElement =
p []
[ mark
[ Name "result"
Class resultClass ] [ str text ] ]
```

Calling `equationOutputContent "tertiary" "3"`

will render the following HTML:

```
<p><mark name="result" class="tertiary">3</mark></p>
```

Did you note that the return type of the `equationOutputContent`

function was of type `ReactElement`

? This gives away the fact that Fable (by default) compiles to React code, in order to actually render the website.

In Elmish, rendering a UI is not much more than just composing functions. We’ll skip over the other functions, but if you’re interested in this bit you can just check out the source code.

And with that we now have a website where we can solve RPN equations using WebAssembly:

# Conclusion

Using F# to parse and solve RPN equations was almost trivial. Modelling the domain using F#’s expressive and low-ceremony type system was an absolute joy. If you are interested in domain modeling using functional techniques, I highly recommend Scott Wlaschin’s Domain Modeling made Functional book.

Generating WebAssembly to solve RPN equations was not very hard. This was helped by the well-written WebAssembly specification. Building the website in F# using Fable was a first for me, but I absolutely loved it. The Elmish part especially was conceptually very appealing, with its simple, functional architecture. Defining HTML output using functions took some time to get used to, but when it did, I really liked it.

The source code of everything described in this blog post can be found at https://github.com/erikschierboom/krakow. You can try out the website at https://krakow-98706.firebaseapp.com/.