Purpose of Kernel

Chat / Discussions
, ,
1

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:

  1. Functions/macros necessary for the structure of the language or that are useful to be default imported, operators/def*/if/max/is_* etc.
  2. Functions that operate on multiple data types, get_in/update_in etc.
  3. Functions that don’t fit anywhere else, like maybe apply
  4. 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.

2 Likes
2

One reason is that Kernel is imported everywhere by default and it contains core functions which other elixir constructs is built upon.

See the module documentation for Kernel

3

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.size and Tuple.elem in guards, it would be extremely confusing to most why then we can’t use something like Map.get in 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.

7 Likes
4

Thanks for the explanation! :slight_smile:

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.

2 Likes
5

Btw, we already have the X.y problem (not being a subset of Kernel) with defguard:

iex(1)> defmodule Foo do
...(1)>   defguard is_even(v) when is_integer(v) and rem(v, 2) == 0
...(1)> end
iex(2)> require Foo
iex(3)> defmodule Bar do
...(3)>   def baz(v) when Foo.is_even(v) do v + 1 end
...(3)>   def baz(v) do v - 1 end
...(3)> end
6

Possibly the Access module could be a good place for get_in etc

7

Personally I think that best way is to have Kernel.Guards which will contain delegates to other modules. Then we will have list of guards well documented in one module + all implementations will be in other modules like List or Map + we can automatically import Kernel.Guards as same as Kernel. I know that such changes will not come soon (if any), but I’m just curious what do you think about it @josevalim.

1 Like
8

There are a couple issues here:

  • Some (most) implementations will still need to be Kernel. For example, comparison/equality/arithmetic operators. Therefore, if we import both Kernel and Kernel.Guards, we will have conflicts
  • Having both elem/2 and Tuple.elem/2 means two ways of doing the same thing
  • The functions in Kernel.Guards are not available only in guards - this may be a documentation concern
9

I had in mind “normal” functions 
 I totally forgot about operators, sorry

For me it’s not a problem if we are using delegates - of course note that such function is delegated should exists in docs. It would be awesome if there would be a mark for it on summary functions list like: function(arg1, arg2) [delegate]

Then in Function section:

elem(tuple, index)                                                                                    [delegate]
elem(tuple(), non_neg_integer()) :: term()
This is delegated function for Tuple.elem/2

Personally I would like to see something like:

Kernel.Guards

This module groups special core functions which are allowed to be called inside guards, for example

# example defguard code here 


Nested guards

Guards allows also other guards to be called inside it, for example

# previous example
# example defguard which uses first example

Syntactic sugar in guards

Except functions grouped in this module and other guards we allow to use also arithmetic, comparison and equality operators which needs to be placed in Kernel module, for example:

# example defguard code with any operator

Old-way guards

Few words about macros here with a link to Macro module for more information 


Using guards

Few sentences about example usage in when and function body.

Summary

Summary content here 


Functions

Functions content here 


Of course I wrote it quickly, so this documentation will contain much more and much better text.

10

It is not a concern implenentation wise. Just from the point of view of the usage of the language. When would you use elem/2 and when would you use Tuple.elem/2?

It feels like we are adding more categories and distinctions? How are they helpful? Why do we care if a guard is coming from Kernel or another module?

1 Like
11

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.

3 Likes
12

Probably I would use always imported version from Kernel.Guards. I believe calling Tuple.elem/2 would be really rare case.

I just think that such module is easiest way to solve problem with moving functions to modules like List or Map + document well why Tuple.elem/2 is able to be used in guard. Even moving 16 type-check and 17 guard-friendly functions would help a lot. Maybe it would be also helpful to group documentation for such functions (like we are doing it for modules).

13

I do wish guards had their own ‘name’ namespaces, just like how macro’s get compiled to :"MACRO-..." prefixed names, I wish guards had a :"GUARD-..." namespaces name, would make things like testing if in a guard or not unnecessary in function as each would have to be done via their own def/defguard. Many other things could be done on top of that


But yeah, I do wish Guards were not in Kernel but where imported via Kernel, say from Kernel.Guards or so as well. At the very least the documentation aspect would be more clear.

However, I don’t see the point in changing it, it works well as it is, as long as it continues the follow the pattern it uses (consistency is paramount, unlike the inconsistent multi-arg for/with oddities ^.^;).