SwiftUI's syntax is unmistakable in regards to building views — instead of assigning properties to your view, you just apply a modifier that returns another view:

```swift
Text("Hello, world!")
 .bold()
 .foregroundColor(.red)
```

This "style" of writing views is very similar to the builder pattern in other languages. But let's say that you already have a bunch of existing types in your project that you're refactoring to use the builder pattern, or you want to apply the builder pattern to types from other libraries. It would definitely be tedious to create functions for every property in every type. Let's see if we can use Swift's powerful type system to do the leg work for us!

> Note that I'm not advocating for or against using the builder pattern in a specific project — this article is more of an exploration into how to implement it in a generic fashion. With that said, let's get started!

It turns out that Swift actually lets us dynamically access properties on a given type, without having to know anything about that type beforehand, using something called **dynamic member lookup**. All you need to do is add the `@dynamicMemberLookup` attribute to your type, and then you can access any random property of the constraints you choose:

```swift
@dynamicMemberLookup
struct SomeType {
 ...
}

let someValue = SomeType()
someValue.foo // works
someValue.someRandomProperty // works
someValue.asdfghjkl // works
```

Dynamic member lookup is actually just syntax sugar for a special variant of a subscript, and it looks like this:

```swift
@dynamicMemberLookup
struct SomeType {
 subscript(dynamicMember key: String) -> Any {
 ...
 }
}

someValue.foo == someValue[dynamicMember: "foo"]
```

In addition to passing an arbitrary string, you can also constrain both the `dynamicMember:` parameter and the subscript's return value to a specific type. You can even use generics! This will make it a lot easier to implement what we're aiming for, so let's start by creating a generic `Builder` type:

```swift
@dynamicMemberLookup
struct Builder<T> {
 private var value: T

 init(_ value: T) {
 self.value = value
 }
}
```

We can use this by calling `Builder(MyType())`. Great! Now let's implement the subscript:

```swift
extension Builder {
 subscript(dynamicMember keyPath: WritableKeyPath<T, U>) -> (U) -> Builder<T> {
 return { self.value[keyPath: keyPath] = $0 }
 }
}
```

Woah! There's a lot going on there, so let's break it down step by step.

The first thing that we need to focus on is the use of **key paths** — if you haven't heard of them before, key paths are a concise way to represent a property on a specific type. You write them as `\MyType.property`, or just `\.property` if `MyType` can be inferred. One good use of key paths is when you're mapping an array:

```swift
let names = ["alice", "bob", "charles"]

names.map { $0.capitalized } // ["Alice", "Bob", "Charles"]
names.map(\.capitalized)
```

Here, a key path is being used to specify that we want to access the `capitalized` property on each string. It's the same as creating a closure that returns the `capitalized` property, but it's a bit more concise. The type of a key path is `KeyPath<T, U>`, where `T` is the type of the value you're accessing the property of, and `U` is the type of the property being accessed.

Back to our example:

```swift
subscript(dynamicMember keyPath: WritableKeyPath<T, U>)
```

So here instead of using a regular key path, we're just using a writable key path — same thing, except we also get to **assign** values to the property being accessed. By constraining the type of `dynamicMember:` to a key path, we only allow users of `Builder` to call functions whose name and type match that of the original value they passed into the `Builder` instance. And we get code completion now, too — neat!

If that didn't make 100% sense, here's an example in code:

```swift
@dynamicMemberLookup
struct UnconstrainedAccess {
 subscript(dynamicMember key: String) -> Any {
 ...
 }
}

let unconstrained = UnconstrainedAccess()
unconstrained.foo // works
unconstrained.asdfghjkl // works

...

struct Person {
 var name: String
 var age: Int
}

@dynamicMemberLookup
struct ConstrainedAccess {
 subscript(dynamicMember keyPath: KeyPath<Person, U>) -> U {
 // Any arbitrary key path can be accessed using the
 // value[keyPath: ...] subscript. foo[keyPath: \.bar] == foo.bar
 return self.someInstanceOfPerson[keyPath: keyPath]
 }
}

let constrained = ConstrainedAccess(...)
constrained.name // works, is of type String
constrained.age // works, is of type Int
constrained.foo // error!

// Also note that this is all still just syntax sugar:
constrained.name == constrained[dynamicMember: \Person.name]
```

Now let's focus on what our subscript is returning:

```swift
subscript(...) -> (U) -> Builder<T> {
 return { self.value[keyPath: keyPath] = $0 }
}
```

In the previous example with `ConstrainedAccess`, we implemented a dynamic member lookup that just sent back the value of the property accessed by the key path. Here, we're sending back a **function** that can be called with the value we want to assign to the given property of the underlying `self.value`. Then from that function, we return the original `Builder` instance, letting us chain multiple calls together. This gives us our SwiftUI-like syntax:

```swift
Builder(someInstanceOfPerson)
 .name("Alice")
 .age(42)
```

If you've been following along really closely, you may have said "But wait! That resolves to a value of `Builder<Person>`, not `Person`!" You would be correct — for that, we can just define a `build()` function that returns the underlying value:

```swift
extension Builder {
 func build() -> T { self.value }
}
```

So now we can do:

```swift
Builder(someInstanceOfPerson)
 .name("Alice")
 .age(42)
 .build()
```

And we get a `Person` value! There's one more issue, though — we have to pass in an _existing_ instance of `Person`, just so its values can be modified once again. Ideally we'd use our builder implementation to "initialize" our value from start to finish. In this case, we can define a `Buildable` protocol that requires an empty initializer, so any properties on the type we want to use must have default values:

```swift
protocol Buildable {
 init()
}
```

And to make our implementation even more concise, we can define a static `builder()` function directly on the `Buildable` protocol:

```swift
extension Buildable {
 static func builder() -> Builder<Self> {
 Builder(Self())
 }
}
```

And now adopting the builder pattern is a breeze!

```swift
struct Person: Buildable {
 // Make sure to provide default values
 var name: String = ""
 var age: Int = 0
}

Person.builder()
 .name("Alice")
 .age(42)
 .build()
```

Here's the entire implementation of `Builder` and `Buildable`:

```swift
@dynamicMemberLookup
struct Builder<T> {
 private var value: T

 init(_ value: T) {
 self.value = value
 }

 subscript(dynamicMember keyPath: WritableKeyPath<T, U>) -> (U) -> Builder<T> {
 return { self.value[keyPath: keyPath] = $0 }
 }
}

protocol Buildable {
 init()
}

extension Buildable {
 static func builder() -> Builder<Self> {
 Builder(Self())
 }
}
```

One interesting potential use case for this could be, in fact, SwiftUI related — take a look 👀

```swift
self.view.addSubview(
 UIImageView.builder()
 .image(UIImage(named: "..."))
 .contentMode(.scaleAspectFit)
 .tintColor(.red)
 .constraints {
 // implementation of the `constraints` builder
 // method is left as an exercise to the reader :)
 }
 .build()
)
```

I hope you enjoyed this article — I hope to post more like it soon! Thanks for reading!

Using dynamic member lookup to implement the builder pattern

Currently in Swift the `zip` function is implemented similar to this:

```swift
// The actual signature/implementation is different than this for performance
// reasons, but the end functionality is the same
func zip<Element>(_ array1: [Element], array2: [Element]) -> [(Element, Element)]
```

To make this more "Swifty", we could make it an array initializer:

```swift
extension Array where Element == (Element, Element) {
 init(zipping array1: [Element], with array2: [Element])
}
```

...but wait, now we have two definitions of `Element`, with one defined in terms of other. That's a problem, because we can't conform `Element` to two different types at the same time, and we certainly can't have it be defined recursively!

To solve this problem, we need to be able to define **"generic extensions"** — I'm not really sure what that would look like or how it would work, but to my knowledge it currently isn't possible in Swift. That's why `zip` must be a global function — it must know the type of `Element` beforehand (via its generic argument) in order to evaluate the return type. When we're defining extensions for existing types, that logic is kind of backwards.

I'm curious as to how this could be written. Maybe something like this?

```swift
extension<ZippingElement> Array where Element == (ZippingElement, ZippingElement) {
 init(zipping array1: [ZippingElement], with array2: [ZippingElement])
}
```

I also wonder if other languages have the concept of "generic extensions" or anything similar. I'll do some research!

“Generic extensions”?

I've been working on my programming language [Wipple](https://github.com/wipplelang/wipple) recently and it's starting to come together. Here are some code examples!

This first one is from `enum.wpl`, which enables the creation of enumerations with associated values and pattern matching:

```wipple
use (import "list");
use (import "uuid");

-- Create an enumeration with the provided cases and associated values.
--
-- Parameters:
-- - `cases`: A list of case names and associated values, in the form
-- `(<case name 1> <associated values 1> <case name 2> <associated values 2> ...)`.
--
-- Returns a structure whose members are functions that correspond to each case;
-- that is, the member name is the case name and the function parameters are the
-- associated values.
--
-- You can use the `match` function to choose a value based on the selected case.
--
-- Example:
--
-- Result = Enum (
-- ok (value)
-- error (error)
-- );
--
-- ok-result = (Result.ok 42);
--
-- -- `format` returns a function that is called with the associated value.
-- write-line! (ok-result |> (match [
-- Result.ok (format "Success! _")
-- Result.error (format "Failure: _")
-- ]))
--
-- -- Displayed: "Success! 42"
Enum = 'cases ->
 cases
 |> (chunk 2)
 |> (each (case -> {
 case-name = case @ 0;
 associated-value-names = case @ 1;

 case-id = uuid!;

 -- Create a function uniquely associating the provided value with
 -- the case
 associated-value-fn = (fn-from-parameter-list associated-values-names);

 -- Add this function to a struct entry with the case name
 [case-name associated-value-fn]
 }))
 |> Struct;


-- TODO
match = cases -> value -> ...;


Package (Enum match)
```

(I haven't quite finished `match` yet — I'll update this post soon!)

Here's the example from the documentation rendered out:

```wipple
Result = Enum (
 ok (value)
 error (error)
);

ok-result = (Result.ok 42);

-- `format` returns a function that is called with the associated value.
write-line! (ok-result |> (match [
 Result.ok (format "Success! _")
 Result.error (format "Failure: _")
]))

-- Displayed: "Success! 42"
```

And here's how that `fn-from-parameter-list` function would be implemented:

```wipple
use (import "list");

-- Convert a list of parameter names and a return value into a curried function.
--
-- Example:
--
-- add3 = (fn-from-parameter-list '(a b c) (a + b + c));
--
-- -- add3 is equivalent to a -> b -> c -> a + b + c
-- add3 1 2 3 -- 6
fn-from-parameter-list = parameters -> return-value ->
 parameters
 |> reverse
 |> (combine return-value (result -> parameter -> ['Fn parameter result]));
```

More examples coming soon!

Some examples of Wipple code

I’ve been working a lot with SwiftUI lately, and one issue I keep running into is dealing with binding to an `Optional` state value. So I wrote these simple little `Binding` extensions (they should be self-explanatory) — I hope you find them useful!

```swift
import SwiftUI

extension Binding {
 init(forceUnwrapping optional: Binding<Value?>) {
 self.init(
 get: { optional.wrappedValue! },
 set: { optional.wrappedValue = $0 }
 )
 }

 init(unwrapping optional: Binding<Value?>, default: Value) {
 self.init(
 get: { optional.wrappedValue ?? `default` },
 set: { optional.wrappedValue = $0 }
 )
 }
}
```

Let me know what you think, or if there's a better way to be going about this!

Binding Optionals in SwiftUI

I haven't pushed to the [wipplelang/wipple](https://github.com/wipplelang/wipple) repository lately, but I am experimenting around with some new ideas privately. I've been working on some quality-of-life improvements to Wipple — check them out!

1. Statements are now separated with a newline instead of a semicolon. Statement breaks will occur when all preceding statement items are parsed (ie. no open groups) and a newline is encountered:

    ```wipple
    foo -- one statement
    bar -- another statement

    (foo
      bar
      baz
    ) -- one statement
    ```

    The last statement in a block is still the one returned, and empty blocks still evaluate to the empty list.

2. Statements are now just lists — there is no distinct type. The semantics for lists are altered so a single-item list is evaluated as if that item was not in a list:

    ```wipple
    (foo bar) -- call 'foo' with 'bar'
    (foo bar baz) -- call 'foo' with 'bar', and the result with 'baz'
    (foo) -- evaluate 'foo'
    () -- return as-is
    ```

3. Lists with operators are now parsed so they consume all values on both sides until an operator of a higher precedence is reached. This removes the need for explicit lists in many places:

    ```
    bob : person (| age 42 |)
    ```

    In previous versions of Wipple extra parentheses would be required:

    ```wipple
    bob : (person (| age 42 |))
    ```

    Note that if the operator's function evaluates the parameter before returning, and the left-hand- and/or right-hand-side of the operator contains only one value, the single value will be used congruent to the changes in list evaluation above.

4. If an operator is evaluated on its own, the function the operator wraps is returned instead of the operator itself (which is unusable alone):

    ```wipple
    > +
    function -- the 'add' function
    ```

    In previous versions of Wipple:

    ```wipple
    > +
    operator -- the '+' operator
    ```

5. Added `pairlist`, a primitive that groups pairs of values. Pair lists are almost always used with another function, like `struct` or keyed functions. The syntax is `(| a b c d |)`, which will create a pair list with two pairs, `'a b` and `'c d` (ie. the first item in the pair is left unevaluated and the second item is evaluated).

    For example, pair lists are used by `struct`s to associate values with property names:

    ```wipple
    person : struct (|
       name           "Bob"
       age            42
       favorite-color 'blue
    |)
    ```

    In order to evaluate the first pair item as well, you can pass the pair list to the `dynamic` package's `eval-pairlist-keys!`:

    ```wipple
    > a : 1
    ()

    > b : 2
    ()

    > c : 3
    ()

    > d : 4
    ()

    > (| a b c d |)
    pairlist

    > list (| a b c d |) -- need to convert to list to view in wipple
    ((a 1) (c 4))

    > use dynamic
    ()

    > (| a b c d |) |> eval-pairlist-keys! |> list
    ((1 2) (3 4))
    ```

6. Dot syntax has been removed at the parser level; it is now an operator:

    ```
    foo . bar -- access the 'bar' property on the value of 'foo'
    ```

    Because dot syntax was the only thing requiring the `Property` trait from being built-in, this trait is now implemented in the `property` package (which the `struct` package uses as a dependency). The `Property` trait looks like this:

    ```wipple
    Property : trait (name -> value ->
      (Data (|
         name name
         value value
      |))
    )
    ```

    And the `.` operator is defined like this:

    ```wipple
    dot-precedence : 100

    . : operator (|
       precedence    dot-precedence
       associativity left
       call          (base => 'prop => ...)
    |)
    ```

    Note that the `.` operator evaluates the left-hand side for each call. This will probably lead to unexpected behavior if you try chaining `.` calls:

    ```wipple
    a : struct (|
      b '(c d)
    |)

    -- expected: c
    -- actual: error (c is not defined)
    a . b . 0

    -- this is because (c d) is evaluated again after being returned.
    -- above is evaluated like this:
    (a . b) . 0
    (c d) . 0
    error: c is not defined
        in (c d) (file.wpl:12:2)
        ...
    ```

    What you probably want to do is use the `..` operator, which accepts a list of paths to be applied one after the other:

    ```wipple
    > a .. b 0
    c
    ```

    And if you want to do this dynamically, you can use the `dynamic` package's `resolve-path!` function:

    ```wipple
    > use dynamic
    ()

    > path-segment-1 : 'b
    ()

    > path-segment-2 : 1 - 1
    ()

    > resolve-path! a [path-segment-1 path-segment-2]
    c
    ```

7. `...` has been added to the standard library and serves as a placeholder so that incomplete examples can still run. It evaluates to itself:

    ```wipple
    ... : '...
    ```


Wipple updates

Wipple has evolved a lot since my last post! I plan to publish a full writeup of all updates to the language, but for now, I've added a new construct called a directive.

Directives are special constructs that apply to the statement level and operate in three modes:

- Stack mode (stack is reset at end of statement)

 ```wipple
 [stack push key value] -- Push a key-value pair to the stack, overwriting if the key already exists
 [stack pop key] -- Pop the key-value pair from the stack
 [stack get key] -- Get the key-value pair from the stack
 [stack has key] -- Check if the key exists in the stack
 ```

- Environment mode

 ```wipple
 [env set key value] -- Set the key-value pair on the environment
 [env get key] -- Get the key-value pair from the environment
 [env has key] -- Check if the key exists in the environment
 [env del key] -- Remove the key-value pair from the environment if it exists
 [env export key replace/merge/error] -- Set the export mode for a key: 'replace' replaces the value, 'merge' uses the Merge trait, 'error' crashes the program
 ```

- Global mode

 ```wipple
 [global set key value] -- Set the key-value pair globally
 [global get key] -- Get the key-value pair globally
 [global has key] -- Check if the key exists globally
 [global del key] -- Remove the key-value pair globally if it exists
 ```

You can create an env/global-level alias for pushing a value to the stack using the following syntax:

```wipple
[env/global alias foo] -- push a value to the stack, accessible as [foo <value>]
```

For example, you can create a convenient syntax for adding documentation to a variable (inspired by Rust):

```wipple
[env alias doc] ()

-- equivalent to [stack push doc "..."]
[doc "The ratio of a circle's circumference to its diameter"]
pi : 3.14
```

The early design of directives also managed assignment (implementing `:`). To define a variable in the current environment, use the macro `:`, which is implemented as:

```wipple
do {
 foo : 42
 foo -- 42
}

foo -- error
```

To define a variable globally, use `global:` (you should rarely need to do this):

```wipple
do {
 foo global: 42
 foo -- 42
}

foo -- 42
```

Similarly, you can use `::=` for environment-level conformances and `global::=` for global conformances.

More updates coming soon!

New Directives Design in Wipple

I've come up with a paradigm called "trait-oriented programming". After experimenting with it for a while I think it's the most natural way to think about data, and it fits Wipple perfectly! So how does it work?

# Pillars of Trait-Oriented Programming

1. **Traits** uniquely describe how a value can be used in the program.
2. **Values** are simply collections of traits.
3. **Conformances** describe how to derive a trait from a value if a condition is met.

In Wipple, traits are represented by values, meaning that values are just collections of other values. (Eventually, of course, there must be a few intrinsic traits that are actually represented differently by the interpreter.) The important thing to understand here is that **values do not have a single representation** in TOP — instead, traits are used to describe all representations of a value. For example, the number 42 can be represented as an integer, a decimal, a string, a DOM node, etc. All of these representations are equally valid depending on the context, and you can freely switch between them. Given this, there are a few rules regarding the use of traits:

- Use traits to describe **lossless, equivalent** representations of a value; eg. a numeric representation and a string representation can be converted between each other without losing any information.
- Traits that describe **lossy** representations of a value describe the value's behavior, and should be used in contexts when the original value is not important.
- Traits must be pure (ie. no mutation, IO or other side effects) because it doesn't matter where/how they are used.

The rule of using traits to describe lossless, equivalent representations of a value ensures that Wipple remains a "safe" language in regards to datatypes — unlike JavaScript or other loosely-typed languages, nothing is being coerced from one type to another.

Because defining every single trait on every single value would be tedious and inflexible, conformances allow you to describe a **new representation or behavior** of an existing value, assuming it meets certain conditions. When a trait from a value is used that isn't directly defined on the value, it is automatically derived as implemented by the conformance. This means that, in general, you can explicitly define one trait of a value (eg. during the value's creation) and use it as if any of the traits were defined explicitly.

# Some code examples

## Basic traits

Let's consider a trait called `Text` that stores a string representation of a value. If we have some value `x`, we can give it a string representation by explicitly defining `Text`'s value:

```wipple
x :: Text "the amazing x value"
```

Remember that we aren't _reassigning_ `x` here — we're just giving it another representation (`:` is for assignment, `::` is for traits). Now we can define a function, `print`, that uses the `Text` value:

```wipple
print : Text value -> ...
print x
```

In the context of the function, `value` will refer to `"the amazing x value"` when we pass in `x`.

Another important thing to understand is that `"the amazing x value"` is _also_ a value with its own traits. In particular, `"the amazing x value"` has the `Text` trait, which contains itself.

## Conformances

Say we have a `Color` trait that stores an RGB color representation of a value, and say we have `red`, `orange`, `yellow` defined as values containing the `Color` trait. Now if we wanted to make these colors (read: values with a color representation) applicable to `print`, we could manually add the `Text` trait to each of them. The problem, though, is that there may be many more colors, and possibly new ones defined in the future. To solve this, we can define a conformance:

```wipple
Color color ::= Text ...
```

This conformance says that all values containing the trait `Color` can also be represented by the trait `Text` (the `...` is the omitted implementation, which returns a string value and has access to `color`). Now any function accepting a `Text` value can also accept a `Color` value, with no modification to the function's implementation!

```wipple
print red -- works!

green : <some color>
print green -- also works!
```

Keep in mind that conformances can accept any condition — for example, we can say that a list of `Text` values is also `Text`:

```wipple
(List and (each Text)) list ::= Text ...
```

We can also use this approach to create "generic" functions:

```wipple
-- given a trait Add:
add : Add a -> a
```

How does this work? Remember that functions accept the value of the **trait**, not the original value passed into the function. This means that `add` simply delegates to the implementation provided by the `Add` trait of the input. This pattern is called "implementing" a trait, and is more generically defined by the `impl` function:

```wipple
impl : Trait T -> T x -> x
```

Say we have some value `foo` and a trait `Bar`:

```wipple
foo :: Bar (x -> do-something-with x)
```

Then we can call `impl Bar` on `foo` like this:

```wipple
do-something-using-foo : impl Bar foo
foo 42 -- result of 'do-something-with 42'
```

## The transitive property

Wipple does not automatically apply the transitive property to conformances; eg. this code will not work:

```wipple
A x ::= B x
B x ::= C x
x :: A _
C for x
```

You need to explicitly conform `A` to `C` using `B` as the implementation:

```wipple
A x ::= C (B for x)
```

The reason for this is twofold — first, it would be extremely expensive to calculate all possible paths considering the conformance condition can be any validator, and second it causes ambiguity when a value has multiple traits that can be used to derive a conformance through the transitive property.

# Interacting with traits in Wipple

| Operator | Description | Usage |
| --------- | ------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------- |
| `:` | Assign a value to a name | `x : 42` |
| `::` | Add a trait to a value | `x :: Text "the amazing x value"` |
| `::=` | Define a conformance | `(List and (each Text)) list ::= Text ...` |
| `is` | Perform a validation | `when (x is Number) ...` |
| `trait` | Create a new, unique trait that validates its value | `Color : trait (shape (r Number g Number b Number))` `Foo : trait _` |
| `_` | The value containing no traits directly; can be used as a validator that accepts all values | `_` |
| `T for x` | Get the trait value from a value | `Number for x` |
| `impl` | Create a macro that delegates to the trait value | `add : impl Add` |
| `new` | Create a value containing the provided trait | `red : new Color (r 255 g 0 b 0)` |
| `of` | Get the validator of a trait's associated value | `Text = of Text` |
| `->` | Create a function | `inc : x -> x + 1` `inc : Number x -> x + 1` |
| `=>` | Create a macro | `inc! : x => (x : x + 1)` |

## How does `new` work?

```wipple
new : Trait T -> value -> {
 x : _
 x :: T value
 x
}
```

## How does `x is T` work?

Trait values (the container holding the actual trait so it can be referred to by name) conform to the `Validate` trait, which the `is` operator uses to validate the input. If the input contains the trait, or the trait can be derived via a conformance, the validation succeeds.

---

This was a very technical explanation of traits, but I will be publishing more accessible examples soon, as well as a comparison between TOP and other paradigms — stay tuned!

Trait-Oriented Programming in Wipple

As we know, computers are designed to process information — number crunching, handling people's names and phone numbers, showing websites, and more. The problem is that computers are really just machines that can't operate without human guidance. Our job as programmers is to tell the computer what to do, and the way we do that is by writing code. Wipple is a "programming language": similar to languages like English, Wipple is a way to convey meaning, but instead you're having a conversation with the computer!

## Variables

Computers work by taking some input, and using the program they're given to process that input into some output. A program needs a way to refer to the input, and in Wipple we do this by using **names**. Think of names like labels on boxes — they're a way to identify whatever is inside. A mystery box isn't very useful! Names can be one word, like `number` or `color` or `x`, or multiple words separated by a dash, like `favorite-color` or `lorem-ipsum`. When a name refers to a piece of information, it's called a **variable**.

Let's write a program to keep track of a bank account's balance. We can refer to the balance with a name like `balance`! Let's try writing some code in the [playground](https://playground.wipple.gramer.dev/?code=show!%20balance):

```wipple
show! balance
```

You'll see we get an error. How come? The problem is that we haven't told the computer what `balance` actually refers to — it's like having a stray label not attached to any box. In order to make `balance` refer to something, say $75, we can use a colon (`:`, pronounced "is"):

```wipple
balance : 75
```

The above code reads as "balance is 75". Now try running both lines of code at once; on the right you should see:

```
balance ==> 75
```

Now the computer knows that `balance` refers to 75!

(If you still got an error running the code, make sure that `balance : 75` is placed _before_ `show! balance`. If you place it after, it's like trying to read a label before it's attached to a box — you're doing things in the wrong order.)

## Functions

So we have a way to refer to input. But how do we actually _do_ anything with it? In Wipple, we can describe how to transform input into output using what's called a **function**. If you remember from math, the function `f(x) = x + 3` takes some input `x` and multiplies it by 3. Wipple functions are similar — all you have to do is use an arrow (`=>`, pronounced "becomes"):

```wipple
input => output
```

The above code reads as "input becomes output". Whatever is on the left is the input, and whatever is on the right is the output. For example, we can describe adding 3 to a number like so:

```wipple
number => number + 3
```

Here we run into the "mystery box" problem again, though — we have a function but no way to use it! To fix this we can give our function a name:

```wipple
add-three : number => number + 3
```

The above code reads as "add-three is when some number becomes the number plus 3". Or more concisely, "add-three is a function that adds 3 to its input".

In order to use the function, we write `add-three` and then the desired input:

```wipple
add-three 2
```

If you `show!` that in the playground (`show! (add-three 2)`), you get 5!

```
(add-three 2) ==> 5
```

Going back to the bank account example, we can use a function to describe how to deposit money into our account:

```
deposit : amount => balance + amount
```

Finally, let's deposit $50 into our account!

```
show! (deposit 50)
```

```
(deposit 50) ==> 125
```

We can update our balance by updating `balance` to the result of `deposit 50`:

```wipple
balance : deposit 50
```

You can repeat this line of code multiple times to keep adding money!

If you want, you can also define a `withdraw` function and use it in the same way:

```wipple
withdraw : amount => balance - amount
```

Congratulations, now you know how to write basic programs in Wipple! [Here's the full playground](https://playground.wipple.gramer.dev/?code=balance%20%3A%2075%0A%0Adeposit%20%3A%20dollars%20%3D%3E%20balance%20%2B%20dollars%0A%0Abalance%20%3A%20deposit%2050%0Ashow!%20balance%0A%0Awithdraw%20%3A%20dollars%20%3D%3E%20balance%20-%20dollars%0A%0Abalance%20%3A%20withdraw%2010%0Ashow!%20balance) for you to experiment with.

More Wipple guides are coming soon... stay tuned! You can check out the Wipple project [on GitHub](https://github.com/wipplelang/wipple) if you're interested.


A simple introduction to Wipple

I've been working on Wipple quite a lot recently, and I'm proud to say that it's now [available for download](https://wipple.gramer.dev)! Currently it only supports running single files though, so it's time to come up with a module system.

## What are modules?

In Wipple, a module is simply a captured environment (a collection of values that are passed down throughout the program). Any variables, conformances, etc. that are declared within a macro are captured and made available to others in one of two ways:

- Modules conform to `Call`, so accessing variables can be done by calling the module with the variable name, eg. `my-module foo`
- The `use` function merges the module's environment with the current one, eg. `use my-module`

## Declaring modules

Blocks are now declared using square brackets (`[` and `]`), and modules are declared using curly braces (`{` and `}`). The last statement is the result of a block, and a module (ie. an environment) is the result of a module block. For example, the module `person` can be declared and used like this:

```wipple
-- Declare the module 'person'
person : {
 name : "Wilson"
 favorite-color : "orange"
}

-- Access variables within 'person'
person name -- "Wilson"
person favorite-color -- "orange"

-- Bring all variables from 'person' into the current environment
use person
name -- "Wilson"
favorite-color -- "orange"
```

As you can see, modules in Wipple work like objects in other languages without the need for additional syntax! Of course, `use`-ing a module also merges in any other values part of the module's environment, including conformances.

## Scoping

Before modules, Wipple didn't really have a concept of scoping like other languages — the environment was simply copied into closures, `do` constructs and anything else that captured it. With modules, though, we need a way of tracking which values were created inside the immediate environment and which were created in a parent environment (you can access values from parent environments in a module block, but they are not exported). As such, the environment is now defined like so:

```rust
type EnvironmentValues = HashMap<EnvironmentKey, Box<dyn Any>>;

struct Environment {
 values: EnvironmentValues,
 parent: Option<Rc<RefCell<Environment>>>,
}
```

Resolving a variable, for example, would search the immediate environment first, and then any parents. Setting a variable is always done in the immediate environment and parents remain unchanged. You can use a reference (discussed later on in this article) to modify values in parent environments.

Modules would thus be defined like this, since they only capture their immediate environment:

```rust
struct Module {
 values: EnvironmentValues,
}
```

Environment keys also need to be able to describe how their value should be merged into other environments via `use`. We can do that like so:

```rust
struct UseFn(Rc<dyn Fn(&T, &T) -> T>);

impl UseFn {
 fn new(...) -> Self { ... }

 fn take_parent() -> Self {
 UseFn::new(|parent, _| parent.clone())
 }

 fn take_new() -> Self {
 UseFn::new(|_, new| new.clone())
 }
}

// First parameter is parent value, second parameter is new value
struct EnvironmentKey<T> {
 id: Uuid,
 r#use: UseFn<T>,
 // What to do when the key is not in the parent environment
 insert: bool,
}
```

From there, we can define `use` like this:

```rust
impl Environment {
 fn use(&mut self, new: &Environment) {
 for (key, new_value) in new.values {
 match self.values.get_mut(key) {
 Some(parent_value) => {
 let used_value = key.r#use(parent_value, new_value);
 *parent_value = used_value;
 }
 None => {
 if key.insert {
 self.values.insert(key, new_value);
 }
 }
 }
 }
 }
}
```

These examples aren't fully complete and accurate, but you get the idea.

> NOTE: Because merging together operator precedences from different environments is very complex and may result in a different ordering than intended, all operator precedences must be declared globally (see below). In other words, the environment key for operator precedences has a `use` function of `take_parent`.

## Why are modules useful?

Modules allow you to split up your project into multiple files and make a distinction between private and public values, allowing your code to be more organized. Modules are also the primary way of passing "objects" (collections of variables) around and can be used for configurations with named, potentially optional values.

## Usage in Wipple code

In Wipple code, you can declare modules in two ways:

- With module blocks, as shown above
- With the `module` function, which loads another Wipple file as a module

The `module` function resolves paths as follows:

- If the path is relative, search relative to the current file; otherwise, search relative to the project root
- If the path points to a file, append the `.wpl` extension and load the file as a module
- If the path points to a folder, load the `module.wpl` file inside the folder. If this file does not exist, create an implicit module that `use`s all files/folders in the folder in alphabetical order
 - This should help prevent the boilerplate in languages where you need to explicitly export all files from the folder!

Modules are cached based on absolute path. In the future, support will be added for force-reloading modules. Currently modules cannot be mutually recursive (causes a stack overflow), but in the future this will be handled more gracefully.

You can `use` other files like this:

```wipple
-- Loads and uses "foo.wpl" relative to the project root
use (module "foo")
```

For convenience, the `use` function also accepts a text value:

```wipple
use "foo" -- equivalent to the above
```

## Loading interpreter plugins

Interpreter plugins can be loaded using the `load-plugin!` function. Paths are interpreted in the same way as `module`, but you pass a path to the folder containing the plugin, and the correct `.wplplugin` file is selected for the current platform. For example, on macOS, writing `load-plugin! "my-plugin"` would search for a `my-plugin/x86_64-apple-darwin.wplplugin` file relative to the project root.

## The global environment

Files are loaded inside a blank environment whose parent is the global environment. The global environment can be modified by passing a module to `global!`:

```wipple
global! {
 -- foo will be accessible to all files
 foo : 42
}
```

Modules passed to `global!` are `use`d in the global environment. Remember, though, that files (like all modules) won't be able to modify `foo` without also using `global!` — trying to set it with `:` will just create a new `foo` in the file's environment.

## References

If you need to modify something in a parent environment, you can do this:

```wipple
x : 1

use {
 x : 2
}

x -- 2
```

But with this approach, it's not possible to modify values in an environment that isn't a parent. In order to modify values part of any arbitrary environment (including values passed into functions), you can use a reference:

```wipple
x : reference 1

{
 x <- 2
}

x -- 2
```

The `<-` operator updates the reference with a new value. References conform to `Computed`, so referring to a reference by name evaluates to the stored value. You can use the `@` function to suppress the evaluation of `Computed` values, thus returning the reference itself:

```wipple
increment! : x -> [
 x <- x + 1
]

x : reference 1
increment! (@ x)
x -- 2
```

By convention, names referring to closures that mutate references or modify anything outside their own captured environment should have a `!` at the end.

References are stored as `Rc<RefCell<Value>>` values in Rust. In the future, support for weak references will be added to prevent reference cycles.

Thanks for reading! If you want to check out Wipple's implementation, you can visit https://github.com/wipplelang and browse the repositories. To download Wipple, visit https://wipple.gramer.dev.

Wipple’s Module System

I worked a lot on Wipple over the past week — here's what's new!

## Changed block syntax

To make room for modules, blocks now use square brackets (`[]`) instead of curly braces:

```wipple
three : [
   1
   2
   3
]
```

## Modules

[Modules](https://gramer.dev/blog/2021-02-28-wipple-module-system) encapsulate their environment, allowing you to declare variables in a particular scope. Modules are declared using module blocks (which take the `{}` syntax from regular blocks):

```wipple
module : {
    variable : "Hello"
}
```

`variable` won't be accessible outside of the module. If you want to access a variable inside a module, you can call the module as a function, passing the desired name as input:

```wipple
module variable -- "Hello"
```

Alternatively, you can `use` a module to bring all of its variables (as well as any other items in the captured environment, like conformances) into the current environment:

```wipple
use module
variable -- "Hello"
```

## Project management

Project management is now implemented, so you can split code across multiple files. To create a project, add a `project.wpl` file in the root folder containing a `main` variable:

```wipple
-- project.wpl

main : "main"
```

The provided string represents the path to the main file of the project, relative to `project.wpl`.

```wipple
-- main.wpl

show "Hello, world!"
```

Just run `wipple run` in your terminal to run the project:

```shell
$ wipple run
Hello, world!
```

You can also `import` and `use` other files anywhere in your project. For example, you could use the code in `hello.wpl` from `main.wpl`:

```wipple
-- hello.wpl

hello : "Hello, world!"

-- main.wpl

use "hello" -- or "./hello"

show hello
```

Currently `project.wpl` only supports `main`, but support for dependencies and other configuration options will be implemented soon.

## Removed binary operators

Variadic operators can do everything binary operators can, and binary operators were causing some problems in the parser (eg. `2 + 2 + 2` would be evaluated to `4`). Therefore, binary operators have been removed entirely.

## Codebase organization

The [Wipple codebase](https://github.com/wipplelang/wipple) has been reorganized, merging everything into one repository for easier debugging and maintenance. Builds of the interpreter are also now released automatically, and some tests of language semantics have been added.

---

This week, I'll be focusing less on the core language and more on porting our [robotics team's Botball library](https://github.com/tyngsboroughrobotics) to Wipple. Check back here next week for another update!


Wipple Weekly Update

I can't believe it's been over a year since I started working on the Wipple interpreter! I'm still going after my original goal of learning how programming languages work, and as my understanding has increased, so have my ambitions. I want to build the "perfect" programming language that's both natural to learn and extremely powerful and flexible.

Over the past few months, I've been thinking about building a compiler for Wipple — this has a lot of advantages, including the ability to run Wipple code on embedded devices like robots (I plan to use Wipple on my robotics team this year), and full static analysis and typechecking. The Wipple interpreter manages a full graph between traits and relations at runtime, and traverses it on every evaluation. By doing this analysis before the program runs, Wipple code will run faster and be easier to reason about.

I've also been thinking about how to implement a better type system in a way that feels natural to Wipple, and after much experimentation, I've come up with a solution that utilizes function syntax in a streamlined way for many aspects of the language. Let's take a look!

## Functions and values

Let's build a simple Wipple program to start:

```wipple
a : 1
b : 2
sum : a + b
```

This code should be pretty easy to understand; we define `a` and `b` as numbers and take their `sum`. How does this happen? At runtime, `a + b` is computed (ie. an `ADD` instruction is sent to the CPU) and the result is stored. This kind of evaluation occurs implicitly — by simply writing the expression in code, addition is performed.

Now what about functions? Let's refactor the above example to use one:

```wipple
add : a -> b -> a + b
sum : add 1 2
```

Now, the addition is parameterized: it takes place on two unknown inputs. This makes our program more general and enables it to work for _any_ `a` and `b`. We can call `add 1 2` like in the example, or `add 10 20`, or `add` any other numbers.

Let's extend this concept to another part of the language!

## Functions and types

Wipple has always been a strongly-typed programming language — with a compiler, the only difference is that typechecking occurs before the program runs. Every value has a type, which we can express using `::`:

```wipple
42 :: Number
"hello" :: Text
2 + 2 = 4 :: Boolean
show "hello" :: .
```

Just like the _value_ of an expression is determined implicitly, so is the _type_ of an expression. Now let's write a more general example:

```wipple
two : x -> '(x x)
```

This function duplicates its input, returning a pair. If we call `two 42`, we get `(42 42)`; if we call `two "hi"`, we get `("hi" "hi")`, and so on. It's easy to determine the type of the result, but what's the type of the input? Just like a function's _value_ depends on its input, so can we make a function's _type_. This idea is called "parametric polymorphism" (aka. generics), and we can use it to define _type functions_!

```wipple
Two : for A -> '(A A)
```

This definition looks very similar to our regular function definition, but to indicate that the input is a type and not a value, we add the `for` prefix. By convention, types are capitalized. Let's try calling our type function:

```wipple
Two Number
```

This is equivalent to writing `Number -> '(Number Number)`, just like `add 1 2` from the previous section is equivalent to writing `1 + 2`. Now let's try calling `two` with different inputs and see how its type changes:

```wipple
two :: Two

two 42 -- two :: Two Number
two "hi" -- two :: Two Text
```

Great! The compiler takes care of calling our type function based on the type of the input value. Of course, you could still add manual type annotations if you wish:

```wipple
(two :: Two Number) 42
(two :: Two Text) 42 -- error: expected Text, found Number
```

Let's extend this concept one more time.

## Functions and expressions

Wipple is inspired by Lisp, and while its syntax looks much different, fundamentally everything is still an expression. Just like Lisp, you can quote expressions to use them as values:

```wipple
(1 2 3) -- error: 1 is not a function
'(1 2 3) :: List Number
```

But unlike Lisp, the new compiled version of Wipple will use quasiquoting by default, and evaluate each item in a quoted list. That is, the following code is valid:

```wipple
a : 1
b : 2
c : 3

'(a b c) = '(1 2 3) -- True
```

This "filling-in" of inner expressions is shallow, so you can also evaluate complex expressions inside quotes:

```wipple
'((1 + 2) (10 + 20) (100 + 200)) = '(3 30 300) -- True
```

Notice a pattern? Just like evaluation and type inference, the filling-in of quoted expressions is implicit — it occurs automatically whenever you use a `'`. In the Wipple interpreter, parameterized filling is possible with a special template syntax. In the new, compiled Wipple, we can use a _fill function_!

```wipple
rev : fill a b -> '(b a)
```

Calling a fill function doesn't immediately result in evaluation; instead, the unevaluated expressions are passed in as input, and then the filled-in expression is evaluated in place of the call. For example, the following code is valid:

```wipple
assign : fill name value -> '(name : value)

assign num 42
num = 42 -- True
```

## Conclusion

I'm really proud of this extended function syntax. In the future, I hope to extend it even more to support things like [context](https://dotty.epfl.ch/docs/reference/contextual/using-clauses.html) and other cool features! I've been working less on programming lately and more on adapting Wipple's design to better support static analysis, but I hope to start making some real progress again very soon. Be sure to check out the [Wipple Playground](https://playground.wipple.gramer.dev) in the meantime — eventually I plan to migrate it over to [Replit](https://replit.com) and take advantage of their recently-added custom language support!

Thanks for reading, and I look forward to sharing more updates soon.


Extended functions in Wipple

Let's say I wanted to create a random number generator in Wipple. It's easy to do with a function:

```wipple
random-between :: Number -> Number -> Number
random-between : start -> end -> ...
```

But what about a function returning a random number between 0 and 1, for convenience?

```wipple
random :: Number
random : random-between 0 1

a : random
b : random
```

Wait, this is just a regular value — there are no parameters, and it will only be evaluated once (`a = b`)! What we need is a way to have computed values (ie. "getters").

Some languages solve this problem by using a function that simply ignores its parameter:

```wipple
random :: . -> Number
random : _ -> random-between 0 1

a : random .
b : random .
```

Even though `a /= b` here, this just doesn't feel right to me. Instead, we can introduce a new construct that delays the evaluation of its input at runtime:

```wipple
random :: Do Number
random : do (random-between 0 1)

a : do! random
b : do! random

a = b -- False
```

`do` creates a `Do` value, and `do!` evaluates it! Because computed values are impure pretty much by design, the exclamation point in `do!` also serves as a reminder of this. By convention, other Wipple functions that are nondeterministic or modify visible state should also end in an exclamation point.

I don't know much about effects, but perhaps this idea can be extended to support them in the future.


Let's say I wanted to create a random number generator in Wipple...

Computed values in Wipple

I've been trying to simplify and consolidate many different Wipple features. Last time was function syntax, this time is assignment syntax!

What is there to consolidate? Well, variable assignment (`a : b`) is actually fine and I plan to make no changes there. Instead, I am standardizing the syntax for various other declarations so that they all use the `:` operator!

## Variable assignment

First, just a recap on variable assignment, which introduces a new name into the current scope:

```wipple
x : 42

Person : data {
 name :: Text
 age :: Number
}

-- etc.
```

## Conversions

Formerly called "relations" and before that "conformances", I decided to rename this declaration yet again to describe what is actually going on. In Wipple, values can be converted between each other implicitly, simulating interfaces in other languages. For example, we can convert a `Person` value into a `Text` value used by `show`:

```wipple
(p :: Person) is Text : format "_ is _ years old" (p name) (p age)
```

Thanks to Wipple's new static type system, we can also express conversions on the type level, similar to Haskell's typeclasses:

```wipple
Person is Equal : p1 -> p2 -> p1 name = p2 name
Person is Order : p1 -> p2 -> p1 age < p2 age
```

## Type functions

Thanks to this streamlined syntax, conversions can now be parameterized using type functions. (I [wrote about this](/blog/2020-03-24-generic-extensions) a while ago!) This lets us define abstract relationships between two traits:

```wipple
Equal : for T -> trait (T -> T -> Boolean)

Ordering : enum Less-Than Greater-Than Equal
Order : for T -> trait (T -> T -> Ordering)

-- All orderable values are automatically equatable
for T (order : T is Order) -> T is Equal :
 a -> b -> when? (order a b) (Ordering Equal)
```

I've been trying to simplify and consolidate many different Wipple features. Last time was function syntax, this time is assignment syntax!

More consistent assignment syntax in Wipple

In my spree to streamline different parts of Wipple, I've decided to update the type syntax to be more flexible and consistent. Here's how it works!

The first change is that all values can be used in type position now. The type of the value is used, sort of like an implicit `typeof` operator. For example:

```wipple
x : 42
f : n :: x -> n
```

Here, `n` has type `Number`. Note that this paves the way for constants as types (eg. `x :: 42`)!

The second change is that `data` and `enum` no longer return types! Instead, they return "forms" that expand to a value or type depending on where they are used. I already use the form pattern throughout the Wipple compiler, so this is an easy change to make. To the user, this means that `data` and `enum` effectively return "constructor" values that can be used in type position or value position.

```wipple
Integer : data ...

x : Integer 42 -- as a value
f : n :: Integer -> n -- as a type
```

The third change is that `for` now accepts a `where` clause that checks for the existence of traits:

```wipple
show :: for A where (Show A) -> A -> Text
```

This is much better than the previous `Show :: A -> _` syntax, and puts Wipple more in line with Haskell!

In addition, pattern syntax has been extended to support datatypes and traits:

```wipple
Single : data Number

Fields : data {
  foo :: Number
  bar :: Text
}

Trait : for A -> trait A -> A


Single n : Single 42

Fields { foo bar } : Fields {
  foo : 42
  bar : "hello"
}

Trait Number : n -> n
```

Notice that datatypes take their variables, while traits take their type parameters.

The final change is that `for` may only be applied once per expression (ie. it may not be nested), and that type parameters in traits must be filled explicitly as done above. This makes it easier to typecheck things, and shouldn't really even be noticeable.

Stay tuned for more updates!


In my spree to streamline different parts of Wipple, I've decided to update the type syntax to be more flexible and consistent. Here's how it works!

Wipple's updated type syntax

Typeclasses are a powerful construct used in functional programming languages like Haskell. Essentially, they allow you to overload functions so that they can operate on different types. Let's take a look at Wipple's `show` function:

```wipple
show :: Show A => A -> ()
```

This means that `show` accepts any value where `Show` is defined for the value's type. Well what is `Show`? It's a **trait**, Wipple's name for typeclasses. To create a trait, just provide a type definition:

```wipple
A => Show A :: A -> Text
```

> Note: This syntax is lightweight but ambiguous in some edge cases. If you want to add a type annotation on a value like `f x :: A`, you should wrap the value in parentheses: `(f x) :: A`.

In Wipple, a trait is a construct whose value depends on its type. We can provide multiple definitions for `Show` to define it for various types!

```wipple
Show Text : it
Show Number : n -> ...
Show Boolean : b -> if b "True" "False"
```

Another good example of traits in action is the `Equal` trait, which can be defined to support equality on types:

```wipple
A => Equal A :: A -> A -> Boolean

[operator 5] = : Equal  -- = :: Equal A => A -> A -> Boolean
```

Now let's take a look at the `|` (map) operator. What do you think its type is?

```wipple
[operator 7] | : functor -> f -> Functor f functor
```

First, what's a functor??? Without getting too technical, a functor is basically a container that supports the map operation on its contents. For example, we can use `|` with `List`s, `Maybe`s, and `Result`s:

```wipple
'(1 2 3) | increment = '(2 3 4)

Some 1 | increment = Some 2
None | increment = None

Success 1 | increment = Success 2
Error "oh no" | increment = Error "oh no"
```

So, the job of the `|` operator is to take a container holding some value(s) `A`, and apply a function `A -> B` to the value(s) so that we end up with the same container holding the new value(s) `B`. To express this in the type system, we need a new feature — higher-kinded types! It looks like this:

```wipple
(F _) => Functor F :: A => B => (A -> B) -> F A -> F B
```

Notice that instead of providing a type variable like `A`, we provide a "type function" `F` that takes an input `_`. We can then provide the input `A` to build a container `F A`, and so on. For example, we can define `Functor` for `Maybe A`, for any `A`:

```wipple
A => Functor (Maybe A) : f -> x? -> when x? {
    Some x -> Some (f x)
    None -> None
}
```

Thus, the type of `|` is:

```wipple
| :: Functor (F _) => A => B => F A -> (A -> B) -> F B
```

For now, only traits with a single parameter are supported. (This restriction is also present in vanilla Haskell because it causes ambiguity.) But that shouldn't prevent very many use cases!

### The new type function syntax

You may have noticed that I reworked the syntax for what used to be `for` functions. In the new syntax, you declare a single type variable with an optional set of traits for which the type is defined. This syntax is a little more concise while still making clear the difference between implicit and explicit type checking.

```wipple
A => ...  -- introduce type variable A
Show A => ...  -- introduce type variable A where Show A is defined
(Show Equal) A => ...  -- introduce type variable A where Show A and Equal A are defined
(F _) => ...  -- introduce higher-kinded type F
Functor (F _) => ... -- introduce higher-kinded type F where Functor (F _) is defined
```

### Conclusion

All in all, I'm really excited to start working on implementing this in the Wipple compiler. Once I have a working, type safe `|` operator, I can start work on pattern matching and then the standard library!


Typeclasses are a powerful construct used in functional programming languages like Haskell...

Typeclasses and higher-kinded types in Wipple

After months of work, I've finally implemented the Wipple trait system! In this post, I want to explain how to use traits in Wipple programs.

In the same way that a type represents a relationship between unique values (`1 :: Number`, `2 :: Number`, `3 :: Number`, etc.), a trait represents a relationship between unique types. Let's say we have a function called `show` that displays its input on the screen. Ideally, we would be able to provide a value of any type to `show`, as long as the value is "showable". We can express this idea using `where`:

```wipple
show :: A where (Show A) => A -> ()
```

What is `Show`? That's our trait! Let's define it:

```wipple
Show : A => trait (A -> Text)
```

This piece of code means "for any type `A`, to `Show` an `A` means to implement a function that, given a value of type `A`, produces a `Text`".

Now let's do just that — implement the function for our various types!

```wipple
instance Show Text : it -- text is already text


Foo : type

instance Show Foo : just "foo"


Person : type {
    name :: Text
}

instance Show Person : { name } -> format "A person named _" name
```

And now we can call `show` with values of these types:

```wipple
show "Hello, world!" -- Hello, world!
show Foo -- foo
show (Person { name : "Bob" }) -- A person named Bob
```

All in all, I'm very proud of how this turned out! The Wipple typechecker has been one of the most complex pieces of software I've ever written, and I'm glad to be able to finally turn my attention to other parts of the language. Next up is pattern matching and templates/operators — I'll come back to higher-kinded types someday if they prove necessary. Until next time!


After months of work, I've finally implemented the Wipple trait system! In this post, I want to explain how to use traits in Wipple programs.

Hi, I’m Wilson Gramer