# List of all Elm kernel functions

**URL:** <https://discourse.elm-lang.org/t/list-of-all-elm-kernel-functions/10483>\
**Category:** Show and Tell\
**Created:** [November 10, 2025, 4:46pm UTC](https://discourse.elm-lang.org/t/list-of-all-elm-kernel-functions/10483 "2025-11-10T16:46:25Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![rupert](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/rupert/32/1775_2.png) [@rupert](https://discourse.elm-lang.org/u/rupert)\
**Post date:** [November 10, 2025, 4:46pm UTC](https://discourse.elm-lang.org/t/list-of-all-elm-kernel-functions/10483/1 "2025-11-10T16:46:25Z")

</div>

A list of all Elm kernel functions:

> **[All Elm 0.19 Kernel Functions](https://docs.google.com/spreadsheets/d/1FQiuA0Q5l5SMcC-dljGqJILfs4XXIM0sceZ3DyfYYw8/edit?usp=sharing)**
>
> This Sheet is private

Might be useful as a checklist if anyone was to attempt some porting of the Elm kernel to a different platform for example.

---

<div class="post-metadata">

**Author:** ![novid](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/novid/32/4341_2.png) [@novid](https://discourse.elm-lang.org/u/novid)\
**Post date:** [November 10, 2025, 6:42pm UTC](https://discourse.elm-lang.org/t/list-of-all-elm-kernel-functions/10483/2 "2025-11-10T18:42:00Z")

</div>

Well done Rupert! There are some other **Elm Kernel** functions on elm-explorations/\* packages:

- [elm-explorations/benchmark](https://github.com/elm-explorations/benchmark/blob/1.0.2/src/Elm/Kernel)
- [elm-explorations/linear-algebra](https://github.com/elm-explorations/linear-algebra/tree/1.0.3/src/Elm/Kernel)
- [elm-explorations/markdown](https://github.com/elm-explorations/markdown/tree/1.0.0/src/Elm/Kernel)
- [elm-explorations/test](https://github.com/elm-explorations/test/tree/2.2.0/src/Elm/Kernel)
- [elm-explorations/webgl](https://github.com/elm-explorations/webgl/tree/1.1.3/src/Elm/Kernel)

I always wondered what happens if we upgrade Elm Kernel functionality from ES3/ES5 to ES6! Since ECMAScript 2015 is widely supported in all major browsers, what are the performance and security optimizations this kind of updating Kernel code achieves?

---

<div class="post-metadata">

**Author:** ![lydell](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/lydell/32/178_2.png) [@lydell](https://discourse.elm-lang.org/u/lydell)\
**Post date:** [November 10, 2025, 8:43pm UTC](https://discourse.elm-lang.org/t/list-of-all-elm-kernel-functions/10483/3 "2025-11-10T20:43:04Z")

</div>

> [@novid](#):
>
> I always wondered what happens if we upgrade Elm Kernel functionality from ES3/ES5 to ES6! Since ECMAScript 2015 is widely supported in all major browsers, what are the performance and security optimizations this kind of updating Kernel code achieves?

Having worked quite a bit on Elm’s Kernel code, I would say that ES6+ would provide … nothing! Mostly. (I’d love to be proven wrong, though.)

- Performance: If anything, I’d expect _worse_ performance. ES5 is optimized to oblivion, while ES6+ is still being worked on. The TypeScript compiler switched from `let`/`const` back to `var` for performance: [Using `var` in limited contexts to avoid runtime TDZ checks · Issue #52924 · microsoft/TypeScript · GitHub](https://github.com/microsoft/TypeScript/issues/52924)
- Security: I haven’t heard of or thought of ES6 features in the context of security. Do you have an example in mind?
- Convenience: Writing a big app in ES5 would be tedious compared to ES6+. But writing a bit of Elm Kernel code in ES5 isn’t that bad.

But there’s at least one feature from ES6+ that Elm could benefit from: Regex unicode mode! I would love to have that available.

Then there’s the Temporal API that I think would be a great fit for Elm. I’m more excited about Elm using new API:s, than new syntax under the hood.

---

<div class="post-metadata">

**Author:** ![rupert](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/rupert/32/1775_2.png) [@rupert](https://discourse.elm-lang.org/u/rupert)\
**Post date:** [November 11, 2025, 10:38am UTC](https://discourse.elm-lang.org/t/list-of-all-elm-kernel-functions/10483/4 "2025-11-11T10:38:49Z")

</div>

I have added all the elm-explorations ones to the sheet as well - adds another 115. Most of them in elm-explorations/linear-algebra.

> **[All Elm 0.19 Kernel Functions](https://docs.google.com/spreadsheets/d/1FQiuA0Q5l5SMcC-dljGqJILfs4XXIM0sceZ3DyfYYw8/edit?usp=sharing)**
>
> This Sheet is private

Command used to extract all Kernel function calls from Elm code is:

```
find . -name "*.elm" -exec grep -hoE 'Elm\.Kernel\.[^[:space:]]+' {} + | sort -u

```

---

<div class="post-metadata">

**Author:** ![Warry](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/warry/32/3998_2.png) [@Warry](https://discourse.elm-lang.org/u/Warry)\
**Post date:** [November 11, 2025, 7:13pm UTC](https://discourse.elm-lang.org/t/list-of-all-elm-kernel-functions/10483/5 "2025-11-11T19:13:17Z")

</div>

It’s slightly off-topic, but if someone would like to transpile Elm code, I’ve created bytes decoders for elmi/elmo files : [GitHub - Warry/elm-stuff: Decode interfaces (.elmi, i.dat) and objects (.elmo, o.dat) from elm-stuff/](https://github.com/Warry/elm-stuff)

I started but never finished a JS generator based on it, but the kernel part was a nightmare and it kind of discouraged me.

edit: published: [Warry/elm-stuff/](https://package.elm-lang.org/packages/Warry/elm-stuff/1.0.0/)

---

<div class="post-metadata">

**Author:** ![setop](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/setop/32/4331_2.png) [@setop](https://discourse.elm-lang.org/u/setop)\
**Post date:** [November 13, 2025, 7:51pm UTC](https://discourse.elm-lang.org/t/list-of-all-elm-kernel-functions/10483/6 "2025-11-13T19:51:23Z")

</div>

> [Warry/elm-stuff/](https://package.elm-lang.org/packages/Warry/elm-stuff/1.0.0/)

It’s great!  
It worth a dedicated post and also a more detailed example on how to use it.

EDIT: currently, I implemented [this](https://codeberg.org/setop/elm-stuffy/src/branch/main/src/Stuffy.elm), but I’m not sure what to do with the result 🙂

---

<div class="post-metadata">

**Author:** ![novid](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/novid/32/4341_2.png) [@novid](https://discourse.elm-lang.org/u/novid)\
**Post date:** [November 13, 2025, 7:56pm UTC](https://discourse.elm-lang.org/t/list-of-all-elm-kernel-functions/10483/7 "2025-11-13T19:56:56Z")

</div>

### ⚡ Performance Considerations

- **Improved Modularity and Tree Shaking:** ES6 modules (`import`/`export`) enable better bundling and tree shaking, reducing bundle size and improving load times. This leads to faster initial page loads and more efficient caching.

- **Better Memory Management:** ES6 features like `let` and `const` reduce memory leaks by limiting variable scope compared to ES5’s `var`.

- **Async/Await Enhancements:** Replacing ES5 callbacks with ES6 `async/await` improves readability and reduces callback hell, which can indirectly enhance performance by simplifying control flow.

### 🔐 Security Considerations

- **Strict Mode by Default:** ES6 modules enforce strict mode automatically, helping catch common coding errors and preventing unsafe actions like accidental global variable creation.

- **Reduced Global Scope Pollution:** ES6 modules encapsulate code, minimizing exposure to global scope and reducing the risk of variable collisions or unintended overrides.

- **Better Encapsulation:** Features like closures promote encapsulation, making it harder for malicious code to tamper with internal logic.

These are some basic improvements over ES5 design which I’m pretty sure about. So, it might be more than … Nothing!

---

<div class="post-metadata">

**Author:** ![lydell](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/lydell/32/178_2.png) [@lydell](https://discourse.elm-lang.org/u/lydell)\
**Post date:** [November 13, 2025, 8:30pm UTC](https://discourse.elm-lang.org/t/list-of-all-elm-kernel-functions/10483/8 "2025-11-13T20:30:57Z")

</div>

Oh, I replied to a bot. Sneaky! Never mind then.

---

<div class="post-metadata">

**Author:** ![novid](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/novid/32/4341_2.png) [@novid](https://discourse.elm-lang.org/u/novid)\
**Post date:** [November 13, 2025, 8:58pm UTC](https://discourse.elm-lang.org/t/list-of-all-elm-kernel-functions/10483/9 "2025-11-13T20:58:37Z")

</div>

You asked for some resolution about my initial question, and after 3 days of basic research and a consice answer, you call me a Bot! That’s not an appropriate behavior in Elm community, Simon …

---

<div class="post-metadata">

**Author:** ![Warry](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/warry/32/3998_2.png) [@Warry](https://discourse.elm-lang.org/u/Warry)\
**Post date:** [November 13, 2025, 9:44pm UTC](https://discourse.elm-lang.org/t/list-of-all-elm-kernel-functions/10483/10 "2025-11-13T21:44:11Z")

</div>

> [@setop](#):
>
> EDIT: currently, I implemented [this](https://codeberg.org/setop/elm-stuffy/src/branch/main/src/Stuffy.elm), but I’m not sure what to do with the result 🙂

it opens up meta programming if you’re ambitious. for example, from interfaces you could generate JSON encoders/decoders, or generate typescript type definitions.

---

<div class="post-metadata">

**Author:** ![allanderek](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/allanderek/32/1360_2.png) [@allanderek](https://discourse.elm-lang.org/u/allanderek)\
**Post date:** [November 14, 2025, 10:23am UTC](https://discourse.elm-lang.org/t/list-of-all-elm-kernel-functions/10483/11 "2025-11-14T10:23:26Z")

</div>

Also, I have a problem with a large Elm program which takes a long time and a lot of memory to compile. I **think** I’ve narrowed the problem down to large `.elmi` files, which I **think** is related to the compiler expanding out all record field types. Coincidentally I recently posted about this on my blog: [Elm compilation time with large records | Allanderek's blog](https://blog.poleprediction.com/posts/elm-compilation-elmi-files/)

So I think I can possibly make use of this package to further inspect the .elmi files and possibly even come up with a plan to reduce the compilation time. I’ve had some success by making some of the record types opaque (because then they are not expanded), but it’s surprisingly difficult to figure out which records would be best to opaquify (if I’m allowed to make up verbs). It feels like there will definitely be some objective criteria (and hence some algorithm) which would report the ‘best’ records to opaquify.

All of this is to say this (Warry/elm-stuff) is a cracking package and I agree with setop it deserves a post of its own.

---

<div class="post-metadata">

**Author:** ![lydell](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/lydell/32/178_2.png) [@lydell](https://discourse.elm-lang.org/u/lydell)\
**Post date:** [November 14, 2025, 1:15pm UTC](https://discourse.elm-lang.org/t/list-of-all-elm-kernel-functions/10483/12 "2025-11-14T13:15:25Z")

</div>

Great post!

Here’s another thread that also talks about using opaque types to improve compilation speed: [Improving Compilation time: Insights from Elm Compiler Internals](https://discourse.elm-lang.org/t/improving-compilation-time-insights-from-elm-compiler-internals/9028)

I talked to someone at Elm Camp 2025, who said that in a project they work on, they have this convention of having Types.elm files which expose everything, which makes the problem worse since basically _all_ record types are exposed then (and end up in .elmi files). And changing a Types.elm file causes a lot of unrelated files to need re-checking. So that could potentially be something to look into, too.

---

<div class="post-metadata">

**Author:** ![allanderek](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/allanderek/32/1360_2.png) [@allanderek](https://discourse.elm-lang.org/u/allanderek)\
**Post date:** [November 14, 2025, 1:37pm UTC](https://discourse.elm-lang.org/t/list-of-all-elm-kernel-functions/10483/13 "2025-11-14T13:37:50Z")

</div>

Great thanks! I’ll look into both of these, I do not have that `Types.elm` convention, but nevertheless it might be that I can avoid exporting something that I do (though I use elm-review to avoid that).

---

<div class="post-metadata">

**Author:** ![Shojin\_Masuda](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/shojin_masuda/32/4731_2.png) [@Shojin\_Masuda](https://discourse.elm-lang.org/u/Shojin_Masuda)\
**Post date:** [November 15, 2025, 11:33pm UTC](https://discourse.elm-lang.org/t/list-of-all-elm-kernel-functions/10483/14 "2025-11-15T23:33:46Z")

</div>

About a possible improvement by using es6, my friend who was investigating [Closures in recursive calls get shadowed, causing stack overflows · Issue #2017 · elm/compiler · GitHub](https://github.com/elm/compiler/issues/2017) said that he can fix it cleanly if he can use `let`.  
This bug is kind of patched up on [GitHub - Zokka-Dev/zokka-compiler: Fork of compiler for Elm, a functional language for reliable webapps.](https://github.com/Zokka-Dev/zokka-compiler/) , but on that implementation, I heard it creates closure on every iteration to hide `var` from outside of the loop created by tail call optimization, which slows down all the tail calls. So, if we can use `let`, we can avoid creating closures, which should improve performance significantly compared to the patch.

---

<div class="post-metadata">

**Author:** ![Shojin\_Masuda](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/shojin_masuda/32/4731_2.png) [@Shojin\_Masuda](https://discourse.elm-lang.org/u/Shojin_Masuda)\
**Post date:** [November 15, 2025, 11:56pm UTC](https://discourse.elm-lang.org/t/list-of-all-elm-kernel-functions/10483/15 "2025-11-15T23:56:36Z")

</div>

Against our intuition, the problematic part is encoding type aliases to elmi, so, wrapping the blobbed type in just a sum type instead of opaque type also fixes the problem.

---

<div class="post-metadata">

**Author:** ![allanderek](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/allanderek/32/1360_2.png) [@allanderek](https://discourse.elm-lang.org/u/allanderek)\
**Post date:** [November 16, 2025, 10:42am UTC](https://discourse.elm-lang.org/t/list-of-all-elm-kernel-functions/10483/16 "2025-11-16T10:42:28Z")

</div>

Yes, sorry you’re correct, I used the wrong term, I meant custom type/sum type it doesn’t have to be opaque at all. The distinction is really between _structural_ and _nominal_ types, but in Elm custom types are always nominal and record types are structural. A custom type is never expanded to its variants whether or not its variants are hidden within a module which doesn’t export them. The reason for this is that the application of a variant constructor always produces a single nominal custom type (though it may of course be parameterised). Similarly there is no sub-typing in custom types as there is with record types (extensible records). So when type inference compares (unifies) two custom types it only ever needs to consider their names, not the structure of those types since if the names are same then the structure is the same, but that’s not true for record types.

I think there is an interesting avenue to explore in making both custom types and record types structural by default and nominal when made opaque through a module boundary. I discuss this in [this blog post](https://blog.poleprediction.com/posts/structural-custom-types/).

---

<div class="post-metadata">

**Author:** ![turboMaCk](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/turbomack/32/355_2.png) [@turboMaCk](https://discourse.elm-lang.org/u/turboMaCk)\
**Post date:** [November 17, 2025, 10:29am UTC](https://discourse.elm-lang.org/t/list-of-all-elm-kernel-functions/10483/17 "2025-11-17T10:29:13Z")

</div>

Late to the party but I second everything @lydell said.

ES5 remains the best compilation target if you’re not writing the JS.

I will at least give him service and write this for a record.

- **Improved Modularity and Tree Shaking:**  
not for elm where code generation does all the possible tree-shaking that could happen while it’s generating JS. Doing any extra pass has cost for no benefit.

- **Better Memory Management**  
JS is garbage collected language. Lifetime of a identifier has nothing to do with lifetime of a memory. Further VM optimizations work based on own analysis and can optimize things out of scope (closure) even if semantically they should be availabe but provably they are not used. `var` was function scoped while `const` and `let` are block scoped. In elm you don’t even have blocks only functions so even if there would be some novel runtime implementation taking this to account I don’t see how this could be any benefical for elm.

- **Async/Await Enhancements:**  
Async and await are syntax sugar for generators. Elm doesn’t even use generators because it has different concurrency model. But even than generators are just a form of continuations like callbasks and are CSP based in the VM. async await is just syntax suggar. So there are no benefits to generating those to be found.

- **Strict Mode by Default**  
Elm doesn’t compile to modules - it has own module system

- **Reduced Global Scope Pollution:**  
same as above

- **Better Encapsulation:**  
closures are in JS since first version and elm uses those to implement lexical scopes.

Computers are not magic. Buzzwords don’t work as magic spells.

The reason why someone does call someone else a “bot” perhaps can have something to do with someone using LLMs to generate AI slop and then expect real humans with better things to do to spend their time reacting to it. The problem here is the asymmetry of the effort. People are more than willing to help others but also they have better thing to do than to argue with text generators.

And for the hot take. I prefer to write ES5 even by hand compare to ES6 which covers every concept by layer of obfuscating syntax sugar. The only reason I don’t do that is because I’m usually wantitng my code to be understantable to other people. And I always transpile to ES5 in build if I have control over that decision. Because it’s not my place to make hardware and platform I could easily support artificially obsolete.

---

<div class="post-metadata">

**Author:** ![novid](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/novid/32/4341_2.png) [@novid](https://discourse.elm-lang.org/u/novid)\
**Post date:** [November 20, 2025, 9:54pm UTC](https://discourse.elm-lang.org/t/list-of-all-elm-kernel-functions/10483/18 "2025-11-20T21:54:55Z")

</div>

> [@turboMaCk](#):
>
> The reason why someone does call someone else a “bot” perhaps can have something to do with someone using LLMs to generate AI slop and then expect real humans with better things to do to spend their time reacting to it. The problem here is the asymmetry of the effort. People are more than willing to help others but also they have better thing to do than to argue with text generators.

I hear your concern, Marek. My goal isn’t to generate noise but to share ideas worth discussing. Let’s focus on the substance rather than the label. FYI, this is not the first time I’ve been labeled with such terms and it worries me. I’ve been an ambassador for Elm and introduced many SMBs to the community during past 4 years. Every week, I spoke with C-Level executives in such companies, who understands the basic technologies of Web, about How a Language like Elm could benefit them in many ways possible. It took me +1600 hours community work during this period (8 hour per week) for such conversations to be useful. So, I know a little bit about people’s effort and time … I’m just upset of this community and its many hidden biases from its so called respected members!

---

<div class="post-metadata">

**Author:** ![rupert](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/rupert/32/1775_2.png) [@rupert](https://discourse.elm-lang.org/u/rupert)\
**Post date:** [November 20, 2025, 11:02pm UTC](https://discourse.elm-lang.org/t/list-of-all-elm-kernel-functions/10483/19 "2025-11-20T23:02:20Z")

</div>

I think the (wholly unnecessary) bot labelling is because your reply looks like it is AI generated, with the lightning and padlock emojis and bulleted text?

The problem with text based communication is that it is hard to read the nuances and intentions like we would in a face to face conversion. And if we read them wrong and make something out of it we might end up having a storm-in-a-tea-cup. So its best to give the benefit of the doubt - if you really think somones response is not worth your time, you can always ignore and move on too!

So what are we all going to do with this list of kernel functions…?

---

<div class="post-metadata">

**Author:** ![system](https://canada1.discourse-cdn.com/flex035/uploads/elm_lang/original/1X/50a05e53677a2c3b47776d7abd0f113eb50193a1.png) [@system](https://discourse.elm-lang.org/u/system)\
**Post date:** [November 30, 2025, 11:02pm UTC](https://discourse.elm-lang.org/t/list-of-all-elm-kernel-functions/10483/20 "2025-11-30T23:02:45Z")

</div>

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.