ChapelCon/ChapelCon2025-Slides
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Add my initial slides

Browse Source 
Signed-off-by: Danila Fedorin <daniel.fedorin@hpe.com>
This commit is contained in:
Danila Fedorin
2025-10-02 17:52:11 -07:00
commit 59fea61d2d
6 changed files with 1721 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

32
type-level/abstract.txt Normal file
View File

@@ -0,0 +1,32 @@
Chapel’s type system can be surprisingly powerful. In addition to “usual”
features such as generics and polymorphism, Chapel provides the ability to
manipulate types using functions; this involves both taking types as arguments
to functions and returning them from these functions. This can enable powerful
programming techniques that are typically confined to the domain of
metaprogramming.
For example, although Chapel’s notion of compile-time values — ‘param’s — is
limited to primitive types such as integers, booleans, and strings, one can
encode compile-time lists of these values as types. Such encodings can be used
to create compile-time specializations of functions that would be otherwise
tedious to write by hand. One use case for such specializations is the
implementation of a family of functions for approximating differential
equations, the Adams-Bashforth methods. Some variants of these methods can be
encoded as lists of coefficients. Thus, it becomes possible to define a single
function that accepts a type-level list of coefficients and produces a
“stamped out” implementation of the corresponding method. This reduces the
need to implement each method explicitly by hand. Another use case of function
specialization is a type-safe ‘printf’ function that validates that users’
format specifiers match the type of arguments to the function.
More generally, Chapel’s types can be used to encode algebraic sums (disjoint
unions) and products (Cartesian) of types. This, in turn, makes it possible to
build arbitrary data structures at the type level. The lists-of-values case
above is an instance of this general principle. Functions can be defined on
type-level data structures by relying on overloading and type arguments.
Programming in this manner starts to resemble programming in a purely
functional language such as Haskell.
Though this style of programming has not seen much use thus far, it can be a
powerful technique for controlling types of arguments or constructing highly
customized functions with no runtime overhead.

979
type-level/slides.md Normal file
View File

@@ -0,0 +1,979 @@
---
theme: gaia
title: Type-Level Programming in Chapel for Compile-Time Specialization
backgroundColor: #fff
---
<!-- _class: lead -->
<style>
section {
font-size: 25px;
}
blockquote {
padding: 15px;
background-color: #f0f0ff;
}
div.side-by-side {
display: flex;
justify-content: space-between;
gap: 20px;
}
div.side-by-side > div {
flex: 1;
}
</style>
# **Type-Level Programming in Chapel for Compile-Time Specialization**
Daniel Fedorin, HPE
---
# Compile-Time Programming in Chapel
* **Type variables**, as their name suggests, store types instead of values.
```Chapel
type myArgs = (int, real);
```
* **Procedures with `type` return intent** can construct new types.
```Chapel
proc toNilableIfClassType(type arg) type do
if isNonNilableClassType(arg) then return arg?; else return arg;
```
* **`param` variables** store values that are known at compile-time.
```Chapel
param numberOfElements = 3;
var threeInts: numberOfElements * int;
```
* **Compile-time conditionals** are inlined at compile-time.
```Chapel
if false then somethingThatWontCompile();
```
---
# Restrictions on Compile-Time Programming
* Compile-time operations do not have mutable state.
- Cannot change values of `param` or `type` variables.
* Chapel's compile-time programming does not support loops.
- `param` loops are kind of an aception, but are simply unrolled.
- Without mutability, this unrolling doesn't give us much.
* Without state, our `type` and `param` functions are pure.
---
# Did someone say "pure"?
I can think of another language that has pure functions...
* :white_check_mark: Haskell doesn't have mutable state by default.
* :white_check_mark: Haskell doesn't have imperative loops.
* :white_check_mark: Haskell functions are pure.
---
# Programming in Haskell
Without mutability and loops, Haskell programmers use pattern-matching and recursion to express their algorithms.
* Data structures are defined by enumerating their possible cases. A list is either empty, or a head element followed by a tail list.
```Haskell
data ListOfInts = Nil | Cons Int ListOfInts
-- [] = Nil
-- [1] = Cons 1 Nil
-- [1,2,3] = Cons 1 (Cons 2 (Cons 3 Nil))
```
* Pattern-matching is used to examine the cases of a data structure and act accordingly.
```Haskell
sum :: ListOfInts -> Int
sum Nil = 0
sum (Cons i tail) = i + sum tail
```
---
# Evaluating Haskell
Haskell simplifies calls to functions by pickign the case based on the arguments.
```Haskell
sum (Cons 1 (Cons 2 (Cons 3 Nil)))
-- case: sum (Cons i tail) = i + sum tail
= 1 + sum (Cons 2 (Cons 3 Nil))
-- case: sum (Cons i tail) = i + sum tail
= 1 + (2 + sum (Cons 3 Nil))
-- case: sum (Cons i tail) = i + sum tail
= 1 + (2 + (3 + sum Nil))
-- case: sum Nil = 0
= 1 + (2 + (3 + 0))
= 6
```
---
# A Familiar Pattern
Picking a case based on the arguments is very similar to Chapel's function overloading.
* **A very familiar example**:
```Chapel
proc foo(x: int) { writeln("int"); }
proc foo(x: real) { writeln("real"); }
foo(1); // prints "int"
```
* **A slightly less familiar example**:
```Chapel
proc foo(type x: int) { compilerWarning("int"); }
proc foo(type x: real) { compilerWarning("real"); }
foo(int); // compiler prints "int"
```
---
# A Type-Level List
Hypothesis: we can use Chapel's function overloading and types to write functional-ish programs.
<div class="side-by-side">
<div>
```Chapel
record Nil {}
record Cons { param head: int; type tail; }
type myList = Cons(1, Cons(2, Cons(3, Nil)));
proc sum(type x: Nil) param do return 0;
proc sum(type x: Cons(?i, ?tail)) param do return i + sum(tail);
compilerWarning(sum(myList) : string); // compiler prints 6
```
</div>
<div>
```Haskell
data ListOfInts = Nil
| Cons Int ListOfInts
myList = Cons 1 (Cons 2 (Cons 3 Nil))
sum :: ListOfInts -> Int
sum Nil = 0
sum (Cons i tail) = i + sum tail
```
</div>
</div>
---
# Type-Level Programming at Compile-Time
After resolution, our original program:
```Chapel
record Nil {}
record Cons { param head: int; type tail; }
type myList = Cons(1, Cons(2, Cons(3, Nil)));
proc sum(type x: Nil) param do return 0;
proc sum(type x: Cons(?i, ?tail)) param do return i + sum(tail);
writeln(sum(myList) : string); // compiler prints 6
```
Becomes:
```Chapel
writeln("6");
```
There is no runtime overhead!
---
# Type-Level Programming at Compile-Time
> Why would I want to do this?!
>
> \- You, probably
* Do you want to write parameterized code, without paying runtime overhead for the runtime parameters?
- **Worked example**: linear multi-step method approximator
* Do you want to have powerful compile-time checks and constraints on your function types?
- **Worked example**: type-safe `printf` function
---
<!-- _class: lead -->
# Linear Multi-Step Method Approximator
---
# Euler's Method
A first-order differential equation can be written in the following form:
$$
y' = f(t, y)
$$
In other words, the derivative of of $y$ depends on $t$ and $y$ itself. There is no solution to this equation in general; we have to approximate.
If we know an initial point $(t_0, y_0)$, we can approximate other points. To get the point at $t_1 = t_0 + h$, we can use the formula:
$$
\begin{align*}
y'(t_0) & = f(t_0, y_0) \\
y(t_0+h) & \approx y_0 + h \times y'(t_0) \\
& \approx y_0 + h \times f(t_0, y_0)
\end{align*}
$$
We can name the the first approximated $y$-value $y_1$, and set it:
$$
y_1 = y_0 + h \times f(t_0, y_0)
$$
---
# Euler's Method
On the previous slide, we got a new point $(t_1, y_1)$. We can repeat the process to get $y_2$:
$$
\begin{array}{c}
y_2 = y_1 + h \times f(t_1, y_1) \\
y_3 = y_2 + h \times f(t_2, y_2) \\
y_4 = y_3 + h \times f(t_3, y_3) \\
\cdots \\
y_{n+1} = y_n + h \times f(t_n, y_n) \\
\end{array}
$$
---
# Euler's Method in Chapel
This can be captured in a simple Chapel procedure:
```Chapel
proc runEulerMethod(step: real, count: int, t0: real, y0: real) {
var y = y0;
var t = t0;
for i in 1..count {
y += step*f(t,y);
t += step;
}
return y;
}
```
---
# Other Methods
* In Euler's method, we look at the slope of a function at a particular point, and use it to extrapolate the next point.
* Once we've computed a few points, we have more information we can incorporate.
- When computing $y_2$, we can use both $y_0$ and $y_1$.
- To get a good approximation, we have to weight the points differently.
$$
y_{n+2} = y_{n+1} + h \left(\frac{3}{2}f(t_{n+1}, y_{n+1}) - \frac{1}{2}f(t_{n}, y_{n})\right)
$$
- More points means better accuracy, but more computation.
* There are other methods that use more points and different weights.
- Another method is as follows:
$$
y_{n+3} = y_{n+2} + h \left(\frac{23}{12}f(t_{n+2}, y_{n+2}) - \frac{16}{12}f(t_{n+1}, y_{n+1}) + \frac{5}{12}f(t_{n}, y_{n})\right)
$$
---
# Generalizing Multi-Step Methods
Explicit Adams-Bashforth methods in general can be encoded as the coefficients used to weight the previous points.
| Method | Equation | Coefficient List
|---------------------------|--------------------------------------|-----------------
| Euler's method | $y_{n+1} = y_n + h \times f(t_n, y_n)$ | $1$
| Two-step A.B. | $y_{n+2} = y_{n+1} + h \left(\frac{3}{2}f(t_{n+1}, y_{n+1}) - \frac{1}{2}f(t_{n}, y_{n})\right)$ | $\frac{3}{2},-\frac{1}{2}$
---
# Generalizing Multi-Step Methods
Explicit Adams-Bashforth methods in general can be encoded as the coefficients used to weight the previous points.
| Method | Equation | Chapel Type Expression
|---------------------------|--------------------------------------|-----------------
| Euler's method | $y_{n+1} = y_n + h \times f(t_n, y_n)$ | `Cons(1,Nil)`
| Two-step A.B. | $y_{n+2} = y_{n+1} + h \left(\frac{3}{2}f(t_{n+1}, y_{n+1}) - \frac{1}{2}f(t_{n}, y_{n})\right)$ | `Cons(3/2,Cons(-1/2, Nil))`
---
# Supporting Functions for Coefficient Lists
```Chapel
proc length(type x: Cons(?w, ?t)) param do return 1 + length(t);
proc length(type x: Nil) param do return 0;
proc coeff(param x: int, type lst: Cons(?w, ?t)) param where x == 0 do return w;
proc coeff(param x: int, type lst: Cons(?w, ?t)) param where x > 0 do return coeff(x-1, t);
```
---
# A General Solver
```Chapel
proc runMethod(type method, h: real, count: int, start: real,
in ys: real ... length(method)): real {
```
* `type method` accepts a type-level list of coefficients.
* `h` encodes the step size.
* `start` is $t_0$, the initial time.
* `count` is the number of steps to take.
* `in ys` makes the function accept as many `real` values (for $y_0, y_1, \ldots$) as there are weights
---
# A General Solver
```Chapel
param coeffCount = length(method);
// Repeat the methods as many times as requested
for i in 1..count {
// We're computing by adding h*b_j*f(...) to y_n.
// Set total to y_n.
var total = ys(coeffCount - 1);
// 'for param' loops are unrolled at compile-time -- this is just
// like writing out each iteration by hand.
for param j in 1..coeffCount do
// For each coefficient b_j given by coeff(j, method),
// increment the total by h*bj*f(...)
total += step * coeff(j, method) *
f(start + step*(i-1+coeffCount-j), ys(coeffCount-j));
// Shift each y_i over by one, and set y_{n+s} to the
// newly computed total.
for param j in 0..< coeffCount - 1 do
ys(j) = ys(j+1);
ys(coeffCount - 1) = total;
}
// return final y_{n+s}
return ys(coeffCount - 1);
```
---
# Using the General Solver
```Chapel
type euler = cons(1.0, empty);
type adamsBashforth = cons(3.0/2.0, cons(-0.5, empty));
type someThirdMethod = cons(23.0/12.0, cons(-16.0/12.0, cons(5.0/12.0, empty)));
```
Take a simple differential equation $y' = y$. For this, define `f` as follows:
```Chapel
proc f(t: real, y: real) do return y;
```
Now, we can run Euler's method like so:
```Chapel
writeln(runMethod(euler, step=0.5, count=4, start=0, 1)); // 5.0625
```
To run the 2-step Adams-Bashforth method, we need two initial values:
```Chapel
var y0 = 1.0;
var y1 = runMethod(euler, step=0.5, count=1, start=0, 1);
writeln(runMethod(adamsBashforth, step=0.5, count=3, start=0.5, y0, y1)); // 6.02344
```
---
# The General Solver
We can now construct solvers for any explicit Adams-Bashforth method, without writing any new code.
---
<!-- _class: lead -->
# Type-Safe `printf`
---
# The `printf` Function
The `printf` function accepts a format string, followed by a variable number of arguments that should match:
```C
// totally fine:
printf("Hello, %s! Your ChapelCon submission is #%d\n", "Daniel", 18);
// not good:
printf("Hello, %s! Your ChapelCon submission is #%d\n", 18, "Daniel");
```
Can we define a `printf` function in Chapel that is type-safe?
---
# Yet Another Type-Level List
- The general idea for type-safe `printf`: take the format string, and extract a list of the expected argument types.
- To make for nicer error messages, include a human-readable description of each type in the list.
- I've found it more convenient to re-define lists for various problems when needed, rather than having a single canonical list definition.
```chapel
record _nil {
proc type length param do return 0;
}
record _cons {
type expectedType; // type of the argument to printf
param name: string; // human-readable name of the type
type rest;
proc type length param do return 1 + rest.length();
}
```
---
# Extracting Types from Format Strings
```Chapel
proc specifiers(param s: string, param i: int) type {
if i >= s.size then return _nil;
if s[i] == "%" {
if i + 1 >= s.size then
compilerError("Invalid format string: unterminted %");
select s[i + 1] {
when "%" do return specifiers(s, i + 2);
when "s" do return _cons(string, "a string", specifiers(s, i + 2));
when "i" do return _cons(int, "a signed integer", specifiers(s, i + 2));
when "u" do return _cons(uint, "an unsigned integer", specifiers(s, i + 2));
when "n" do return _cons(numeric, "a numeric value", specifiers(s, i + 2));
otherwise do compilerError("Invalid format string: unknown format type");
}
} else {
return specifiers(s, i + 1);
}
}
```
---
# Extracting Types from Format Strings
Let's give it a quick try:
```Chapel
writeln(specifiers("Hello, %s! Your ChapelCon submission is #%i\n", 0) : string);
```
The above prints:
```Chapel
_cons(string,"a string",_cons(int(64),"a signed integer",_nil))
```
---
# Validating Argument Types
* The Chapel standard library has a nice `isSubtype` function that we can use to check if an argument matches the expected type.
* Suppose the `.length` of our type specifiers matches the number of arguments to `printf`
* Chapel doesn't currently support empty tuples, so if the lengths match, we know that `specifiers` is non-empty.
* Then, we can validate the types as follows:
```Chapel
proc validate(type specifiers: _cons(?t, ?s, ?rest), type argTup, param idx) {
if !isSubtype(argTup[idx], t) then
compilerError("Argument " + (idx + 1) : string + " should be " + s + " but got " + argTup[idx]:string, idx+2);
if idx + 1 < argTup.size then
validate(rest, argTup, idx + 1);
}
```
* The `idx+2` argument to `compilerError` avoids printing the recursive `validate` calls in the error message.
---
# The `fprintln` overloads
* I named it `fprintln` for "formatted print line".
* To support the empty-specifier case (Chapel varargs don't allow zero arguments):
```Chapel
proc fprintln(param format: string) where specifiers(format, 0).length == 0 {
writeln(format);
}
```
* If we do have type specifiers, to ensure our earlier assumption of `size` matching:
```Chapel
proc fprintln(param format: string, args...)
where specifiers(format, 0).length != args.size {
compilerError("'fprintln' with this format string expects " +
specifiers(format, 0).length : string +
" argument(s) but got " + args.size : string);
}
```
---
# The `fprintln` overloads
* All that's left is the main `fprintln` implementation:
```Chapel
proc fprintln(param format: string, args...) {
validate(specifiers(format, 0), args.type, 0);
writef(format + "\n", (...args));
}
```
---
# Using `fprintln`
```Chapel
fprintln("Hello, world!"); // fine, prints "Hello, world!"
fprintln("The answer is %i", 42); // fine, prints "The answer is 42"
// compiler error: Argument 3 should be a string but got int(64)
fprintln("The answer is %i %i %s", 1, 2, 3);
```
More work could be done to support more format specifiers, escapes, etc., but the basic idea is there.
---
<!-- _class: lead -->
# Beyond Lists
---
# Beyond Lists
* I made grand claims earlier
- "Write functional-ish program at the type level!"
* So far, we've just used lists and some recursion.
* Is that all there is?
---
# Algebraic Data Types
* The kinds of data types that Haskell supports are called *algebraic data types*.
* At a fundamental level, they can be built up from two operations: _cartesian product_ and _disjoint union_.
* There are other concepts to build recursive data types, but we won't need them in Chapel.
- To prove to you I know what I'm talking about, some jargon:
_initial algebras_, _the fixedpoint functor_, _catamorphisms_...
- Check out _Bananas, Lenses, Envelopes and Barbed Wire_ by Meijer et al. for more.
* __This matters because, if Chapel has these operations, we can build any data type that Haskell can.__
---
<style scoped>
li:nth-child(3) { color: lightgrey; }
</style>
# Algebraic Data Types
- The kinds of data types that Haskell supports are called *algebraic data types*.
- At a fundamental level, they can be built up from two operations: _cartesian product_ and _disjoint union_.
- There are other concepts to build recursive data types, but we won't need them in Chapel.
- To prove to you I know what I'm talking about, some jargon:
_initial algebras_, _the fixedpoint functor_, _catamorphisms_...
- Check out _Bananas, Lenses, Envelopes and Barbed Wire_ by Meijer et al. for more.
- __This matters because, if Chapel has these operations, we can build any data type that Haskell can.__
---
# Cartesian Product
For any two types, the _cartesian product_ of these two types defines all pairs of values from these types.
- This is like a two-element tuple _at the value level_ in Chapel.
- We write this as $A \times B$ for two types $A$ and $B$.
- In (type-level) Chapel and Haskell:
<div class=side-by-side>
<div>
```Chapel
record Pair {
type fst;
type snd;
}
type myPair = Pair(myVal1, myVal2);
```
</div>
<div>
```Haskell
data Pair = MkPair
{ fst :: A
, snd :: B
}
myPair = MkPair myVal1 myVal2
```
</div>
</div>
---
# Disjoint Union
For any two types, the _disjoint union_ of these two types defines values that are either from one type or the other.
- This is _almost_ like a `union` in Chapel or C...
- But there's extra information to tell us which of the two types the value is from.
- We write this as $A + B$ for two types $A$ and $B$.
- In Chapel and Haskell:
<div class=side-by-side>
<div>
```Chapel
record InL { type value; }
record InR { type value; }
type myFirstCase = InL(myVal1);
type mySecondCase = InR(myVal2);
```
</div>
<div>
```Haskell
data Sum
= InL A
| InR B
myFirstCase = InL myVal1
mySecondCase = InR myVal2
```
</div>
</div>
---
# Algebraic Data Types
* We can build up more compelx types by combining these two operations.
* Need a triple of types $A$, $B$, and $C$? Use $A \times (B \times C)$.
* Similarly, "any one of three types" can be expressed as $A + (B + C)$.
* A `Result<T>` type (in Rust, or `optional<T>` in C++) is $T + \text{Unit}$.
* `Unit` is a type with a single value (there's only one `None` / `std::nullopt`).
* Notice that in Chapel, we moved up one level
| Thing | Chapel | Haskell |
|-------|------------------|-------------------|
| `Nil` | type | value |
| `Cons`| type constructor | value constructor |
| List | **???** | type |
---
# Algebraic Data Types
* Since Chapel has no notion of a type-of-types, we can't enforce that our values are _only_ `InL` or `InR` (in the case of `Sum`).
* This is why, in Chapel versions, type annotations like `A` and `B` are missing.
<div class=side-by-side>
<div>
```Chapel
record Pair {
type fst; /* : A */
type snd; /* : B */
}
```
</div>
<div>
```Haskell
data Pair = MkPair
{ fst :: A
, snd :: B
}
```
</div>
</div>
* So, we can't enforce that the user doesn't pass `int` to our `length` function defined on lists.
* We also can't enforce that `InL` is instantiated with the right type.
* So, we lose some safety compare to Haskell...
* ...but we're getting the compiler to do arbitrary computations for us at compile-time.
---
# Worked Example: Binary Search Tree
In Haskell, binary search trees can be defined as follows:
```Haskell
data BSTree = Empty
| Node Int BSTree BSTree
balancedOneTwoThree = Node 2 (Node 1 Empty Empty) (Node 3 Empty Empty)
```
Written using Algebraic Data Types, this is:
$$
\text{BSTree} = \text{Unit} + (\text{Int} \times \text{BSTree} \times \text{BSTree})
$$
In Haskell (using sums and products):
```Haskell
type BSTree' = Unit `Sum` (Int `Pair` (BSTree' `Pair` BSTree'))
balancedOneTwoThree' = InR (2 `MkPair` (InR (1 `MkPair` (InL MkUnit `MkPair` InL Unit)) `MkPair`
InR (3 `MkPair` (InL MkUnit `MkPair` InL Unit))))
```
---
# Worked Example: Binary Search Tree
* Recalling the Haskell version:
```Haskell
type BSTree' = Unit `Sum` (Int `Pair` (BSTree' `Pair` BSTree'))
balancedOneTwoThree' = InR (2 `MkPair` (InR (1 `MkPair` (InL MkUnit `MkPair` InL Unit)) `MkPair`
InR (3 `MkPair` (InL MkUnit `MkPair` InL Unit))))
```
* We can't define `BSTree'` in Chapel (no type-of-types), but we can define `balancedOneTwoThree'`:
```Chapel
type balancedOneTwoThree =
InR(Pair(2, Pair(InR(Pair(1, Pair(InL(), InL()))),
InR(Pair(3, Pair(InL(), InL()))))));
```
* :white_check_mark: We can use algebraic data types to build arbitrarily complex data structures ◼.
---
# Returning to Pragmatism
* We could've defined our list type in terms of `InL`, `InR`, and `Pair`.
* However, it was cleaner to make it look more like the non-ADT Haskell version.
* Recall that it looked like this:
<div class="side-by-side">
<div>
```Chapel
record Nil {}
record Cons { param head: int; type tail; }
type myList = Cons(1, Cons(2, Cons(3, Nil)));
```
</div>
<div>
```Haskell
data ListOfInts = Nil
| Cons Int ListOfInts
myList = Cons 1 (Cons 2 (Cons 3 Nil))
```
</div>
</div>
* We can do the same thing for our binary search tree:
<div class="side-by-side">
<div>
```Chapel
record Empty {}
record Node { param value: int; type left; type right; }
type balancedOneTwoThree = Node(2, Node(1, Empty, Empty),
Node(3, Empty, Empty));
```
</div>
<div>
```Haskell
data BSTree = Empty
| Node Int BSTree BSTree
balancedOneTwoThree = Node 2 (Node 1 Empty Empty)
(Node 3 Empty Empty)
```
</div>
</div>
---
# A General Recipe
To translate a Haskell data type definition to Chapel:
* For each constructor, define a `record` with that constructor's name
* The fields of that record are `type` fields for each argument of the constructor
- If the argument is a value (like `Int`), you can make it a `param` field instead
* A visual example, again:
<div class="side-by-side">
<div>
```Chapel
record C1 { type arg1; /* ... */ type argi; }
// ...
record Cn { type arg1; /* ... */ type argj; }
```
</div>
<div>
```Haskell
data T = C1 arg1 ... argi
| ...
| Cn arg1 ... argj
```
</div>
</div>
---
# Inserting and Looking Up in a BST
<div class="side-by-side">
<div>
```Chapel
proc insert(type t: Empty, param x: int) type do return Node(x, Empty, Empty);
proc insert(type t: Node(?v, ?left, ?right), param x: int) type do
select true {
when x < v do return Node(v, insert(left, x), right);
otherwise do return Node(v, left, insert(right, x));
}
type test = insert(insert(insert(Empty, 2), 1), 3);
proc lookup(type t: Empty, param x: int) param do return false;
proc lookup(type t: Node(?v, ?left, ?right), param x: int) param do
select true {
when x == v do return true;
when x < v do return lookup(left, x);
otherwise do return lookup(right, x);
}
```
</div>
<div>
```Haskell
insert :: Int -> BSTree -> BSTree
insert x Empty = Node x Empty Empty
insert x (Node v left right)
| x < v = Node v (insert x left) right
| otherwise = Node v left (insert x right)
test = insert 3 (insert 1 (insert 2 Empty))
lookup :: Int -> BSTree -> Bool
lookup x Empty = False
lookup x (Node v left right)
| x == v = True
| x < v = lookup x left
| otherwise = lookup x right
```
</div>
</div>
It really works!
```Chapel
writeln(test : string);
// prints Node(2,Node(1,Empty,Empty),Node(3,Empty,Empty))
writeln(lookup(test, 1));
// prints true for this one, but false for '4'
```
---
# A Key-Value Map
```Chapel
record Empty {}
record Node { param key: int; param value; type left; type right; }
proc insert(type t: Empty, param k: int, param v) type do return Node(k, v, Empty, Empty);
proc insert(type t: Node(?k, ?v, ?left, ?right), param nk: int, param nv) type do
select true {
when nk < k do return Node(k, v, insert(left, nk, nv), right);
otherwise do return Node(k, v, left, insert(right, nk, nv));
}
proc lookup(type t: Empty, param k: int) param do return "not found";
proc lookup(type t: Node(?k, ?v, ?left, ?right), param x: int) param do
select true {
when x == k do return v;
when x < k do return lookup(left, x);
otherwise do return lookup(right, x);
}
type test = insert(insert(insert(Empty, 2, "two"), 1, "one"), 3, "three");
writeln(lookup(test, 1)); // prints "one"
writeln(lookup(test, 3)); // prints "three"
writeln(lookup(test, 4)); // prints "not found"
```
---
# Conclusion
* Chapel's type-level programming is surprisingly powerful.
* We can write compile-time programs that are very similar to Haskell programs.
* This allows us to write highly parameterized code without paying runtime overhead.
* This also allows us to devise powerful compile-time checks and constraints on our code.
* This approach allows for general-purpose programming, which can be applied to `your use-case`