Add two numbers. The number type variable means this operation can be specialized to Int -> Int -> Int or to Float -> Float -> Float. So you can do things like this:

3002 + 4004 == 7006 -- all ints

3.14 + 3.14 == 6.28 -- all floats

You cannot add an Int and a Float directly though. Use functions like toFloat or round to convert both values to the same type. So if you needed to add a list length to a Float for some reason, you could say one of these:

3.14 + toFloat (List.length [ 1, 2, 3 ]) == 6.14

round 3.14 + List.length [ 1, 2, 3 ] == 6

Note: Languages like Java and JavaScript automatically convert Int values to Float values when you mix and match. This can make it difficult to be sure exactly what type of number you are dealing with. When you try to infer these conversions (as Scala does) it can be even more confusing. Gren has opted for a design that makes all conversions explicit.

Subtract numbers like 4 - 3 == 1.

See (+) for docs on the number type variable.

Multiply numbers like 2 * 3 == 6.

See (+) for docs on the number type variable.

Floating-point division:

10 / 4 == 2.5

11 / 4 == 2.75

12 / 4 == 3

13 / 4 == 3.25

14
    / 4
    == 3.5
    - 1
    / 4
    == -0.25
    - 5
    / 4
    == -1.25

Integer division:

10 // 4 == 2

11 // 4 == 2

12 // 4 == 3

13 // 4 == 3

14
    // 4
    == 3
    - 1
    // 4
    == 0
    - 5
    // 4
    == -1

Notice that the remainder is discarded, so 3 // 4 is giving output similar to truncate (3 / 4).

It may sometimes be useful to pair this with the remainderBy function.

Exponentiation

3 ^ 2 == 9

3 ^ 3 == 27

Check if values are “the same”.

Note: Gren uses structural equality on tuples, records, and user-defined union types. This means the values (3, 4) and (3, 4) are definitely equal. This is not true in languages like JavaScript that use reference equality on objects.

Note: Do not use (==) with functions, JSON values from gren/json, or regular expressions from gren/regex. It does not work. It will crash if possible. With JSON values, decode to Gren values before doing any equality checks!

Why is it like this? Equality in the Gren sense can be difficult or impossible to compute. Proving that functions are the same is undecidable, and JSON values can come in through ports and have functions, cycles, and new JS data types that interact weirdly with our equality implementation. In a future release, the compiler will detect when (==) is used with problematic types and provide a helpful error message at compile time. This will require some pretty serious infrastructure work, so the stopgap is to crash as quickly as possible.

Check if values are not “the same”.

So (a /= b) is the same as (not (a == b)).

The logical AND operator. True if both inputs are True.

True && True == True

True && False == False

False && True == False

False && False == False

Note: When used in the infix position, like (left && right), the operator short-circuits. This means if left is False we do not bother evaluating right and just return False overall.

The logical OR operator. True if one or both inputs are True.

True || True == True

True || False == True

False || True == True

False || False == False

Note: When used in the infix position, like (left || right), the operator short-circuits. This means if left is True we do not bother evaluating right and just return True overall.

Put two appendable things together. This includes strings and lists.

"hello" ++ "world" == "helloworld"

[ 1, 1, 2 ] ++ [ 3, 5, 8 ] == [ 1, 1, 2, 3, 5, 8 ]

Saying f <| x is exactly the same as f x.

It can help you avoid parentheses, which can be nice sometimes. Maybe you want to apply a function to a case expression? That sort of thing.

Saying x |> f is exactly the same as f x.

It is called the “pipe” operator because it lets you write “pipelined” code. For example, say we have a sanitize function for turning user input into integers:

-- BEFORE
sanitize : String -> Maybe Int
sanitize input =
    String.toInt (String.trim input)

We can rewrite it like this:

-- AFTER
sanitize : String -> Maybe Int
sanitize input =
    input
        |> String.trim
        |> String.toInt

Totally equivalent! I recommend trying to rewrite code that uses x |> f into code like f x until there are no pipes left. That can help you build your intuition.

Note: This can be overused! I think folks find it quite neat, but when you have three or four steps, the code often gets clearer if you break out a top-level helper function. Now the transformation has a name. The arguments are named. It has a type annotation. It is much more self-documenting that way! Testing the logic gets easier too. Nice side benefit!

Function composition, passing results along in the suggested direction. For example, the following code checks if the result of rounding a float is odd:

not << isEven << round

You can think of this operator as equivalent to the following:

(g << f) == (\x -> g (f x))

So our example expands out to something like this:

\n -> not (isEven (round n))

Function composition, passing results along in the suggested direction. For example, the following code checks if the result of rounding a float is odd:

round >> isEven >> not