Nicd
Purpose of Kernel
Reading this topic, I came to the question:
What is the purpose of the Kernel module?
As I understand it, it somewhat mirrors the :erlang module and contains all functions available in guards. But the problem is, now some map functions are in both Map and Kernel, the same for List. So Kernel contains both functions that work on many datatypes and functions that work only on certain datatypes. If we add the new map_get/2 and is_map_key/2, then map functions will be even more split between Kernel and Map.
This is what I see in Kernel:
- Functions/macros necessary for the structure of the language or that are useful to be default imported, operators/
def*/if/max/is_*etc. - Functions that operate on multiple data types,
get_in/update_inetc. - Functions that don’t fit anywhere else, like maybe
apply - Functions that work on single data types, like
hd/length/elem/map_size
Now category #4 has always bothered me. Why are these functions not in modules, for example Tuple.elem/2? It is very surprising for a new user to see that the most important functions operating on tuples for example are not in Tuple. Even from category #3 some functions could be moved to other modules, like now some spawn functions are in Kernel and some are in Process.
If the reason is Kernel has all the functions that can be used in guards, I think that reasoning isn’t so useful because I still have to go look at the list of functions that I can use in guards as Kernel has other functions as well. I don’t remember the list offhand, so it won’t matter to me if it’s elem/2 or Tuple.elem/2 in the list.
Is there a technical reason for this mixed bag of stuff in Kernel? What does everyone else think about it? I don’t mean to come off as abrasive about it and it’s not the end of the world, it doesn’t come up that often when I program, but I’m just wondering about the reasoning behind it.
Most Liked
josevalim
Yup. As commented on the linked thread:
Correct. Kernel was used to be bigger but we shrunk it before 1.0. The consensus was to keep those in Kernel precisely because they are the only ones available in guards.
Two other things to consider about this:
-
If we allowed
Map.sizeandTuple.elemin guards, it would be extremely confusing to most why then we can’t use something likeMap.getin guards. The lack of namespace reveals that there is something special about them. Today you at least know guards are a subset of Kernel. If we move them to modules, then any function that you have ever seen could be a guard. -
I could easily argue in favor of the guard functions because of #1 too. Imagine how verbose guards would be if each call in a guard had to be fully qualified
I think a good exercise to accompany your question is “how would the language look like if most guards were in potentially separate modules?”. Would it more or less confusing? How easy would it be to discover guards? If you rewrite some existing codebases to the proposed syntax, is it better? Worse?
Of the functions you mentioned, the only ones I would consider misplaced are apply/3 and apply/2, now that we have the Function module (hindsight is 20/20), and potentially get_in and friends, although I would still wonder where would be a good placement for the latter.
michalmuskala
This has one important difference - you need to call require, because it’s a macro. Similar with things defined using defguard, they can’t be “just called”, you need to explicitly opt-in to using them with require. Can you imagine requiring all the Tuple and Map and others to use the guards? Each module would be littered with those.
Nicd
Thanks for the explanation! 
This I have a different opinion on, though, as my only process to discover guards is “google for ‘elixir guards’ and read the list”. Since not all Kernel functions can be used in guards, the only guide I can use is the list of guard functions, and it wouldn’t matter then if they were in different modules. I do agree then reading a guard with Tuple.elem(tpl, 1) could lead to the confusion you mentioned, but finding out which functions are supported is already equally confusing.
Popular in Discussions
Other popular topics
Latest on Elixir Forum
Sponsor Spotlight
Develop your skills with books, videos, and courses.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #javascript
- #code-sync
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Real-time error tracking, performance insights, and observability for devs.
Producing high quality Elixir screencasts since 2017.
Enabling companies to succeed by building software people love.
The deployment platform built for Elixir: PaaS ease, VPS control.
Courses that'll move you from confusion to "Aha, now I get it!"