Is there a way to pipe the cons (list prepend) operator?

Questions / Help
1

You can prepend to a list with:

[item | list]

But is it possible to pipe this operation? I can’t see any way to do this in List/Kernel, and there seems to be very little info about the cons operator in general. I would like to be able to do something like:

list
|> List.prepend(item)

Of course, I could use a custom/anonymous function but is there an inbuilt way to do this?

6 Likes
2

There is List.insert_at

iex(3)> (1..10) |> Enum.to_list |> List.insert_at(0, :foo)
[:foo, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
1 Like
3

Thanks. Perhaps I should be clearer that I’m not looking for alternatives (I’m aware of insert_at), I just want to know if this exact feature exists. Cons is one of the most common operations in Elixir, and piping is similarly ubiquitous, so it would seem odd if you can’t use both together! :stuck_out_tongue:

3 Likes
4

As far as I can tell:

  • Erlang doesn’t actually have a cons “operator” but syntax for a cons cell i.e. [ term1 | term2 ] - and it actually has two distinct uses, to construct a cons cell and to match a cons cell. So it makes sense that it is a language feature rather than an operator backed by a function.
  • Elixir and it’s macro support build on Erlang but the primary objective of the Pipe macro is to take the result of the preceding expression (LHS) and thread it into the first parameter of the next function (RHS) (Clojure actually refers to something like this as the thread first macro rather than a “Pipe”).

So the two simply don’t mix because Erlang’s cons cell predated Elixir and Elixir’s Pipe was designed to work with functions.

Always inquire whether there is an idiomatic way of doing things as commonality makes everybody’s life easier but also realize that sometimes the DIY-as-required approach is often accepted/preferred in order to keep clutter out of the language/platform.

3 Likes
5

Thanks.

So it makes sense that it is a language feature rather than an operator backed by a function.

I’m not sure I quite understand why. Haskell has the same syntax for cons and pattern matching but has cons as a regular operator. Perhaps there is some reason Erlang went a different route? Maybe it was just too complicated to implement. Would be good to know why! :slight_smile:

1 Like
6

Elixir, Erland and Prolog use structural pattern matching, while Haskell uses staticly typed pattern matching.

These are similar, but not the same. For instance, in Haskell you cannot re-use the same name twice to say that two things are equal, you will have to use a guard.

I think this is at least a partial reason.

3 Likes
7

Erlang Master Class 1: Video 8 - Discussion:

FRANCESCO CESARINI: One question I got once is, we’re learning Haskell and you’re giving us a lecture about how Erlang’s being used in the real world. Why are they actually teaching us Haskell, and not Erlang? And a natural answer there was, you’re here to learn how to learn.

I’m being left with the impression that in Haskell functional programming is an end in itself, while in Erlang and Elixir functional programming is merely a means to an end - so Erlang/Elixir seem more practically minded.

Also Erlang (for optimization reasons AFAIK) allows the formation of improper lists with the cons cell.

2 Likes
8

I actually think that improper lists are allowed because the language is dynamically typed. Because consing is so common, why then add an extra check (that has to happen at runtime as it is dynamically typed) to see if the right hand side is a list?

If I remember correctly, most lisps (that are dynamically typed, just like elixir/erlang) allow improper lists because it is not worth this extra check.

You are totally right that Erlang was a language created for a practical purpose where being functional was a ‘side effect’, while Haskell was first a research language, which focused on practicality in the second place.

2 Likes
9

I was thinking IOLists could be improper - but that may have been a bad assumption on my part.

1 Like
10

I think you will find that the cons operator in Haskell x : xs behaves the same way as [x | xs] in Elixir/Erlang both in constructing and in patterns. The difference is only in the syntax

2 Likes
11

You can do something like this

defmodule KernelEx do
  defmacro left :: right do
    quote do
      [unquote(left) | unquote(right)]
    end
  end
end

Then you can use it like this

iex(1)> require KernelEx
KernelEx
iex(2)> 1 |> KernelEx.::([2, 3])
[1, 2, 3]

Note that because :: as other uses in Elixir (in bitstrings and type specs) you cannot import KernelEx

iex(3)> import KernelEx
** (CompileError) iex:8: cannot import KernelEx.::/2 because it conflicts with Elixir special forms
    (elixir) src/elixir_import.erl:108: :elixir_import.calculate/6
    (elixir) src/elixir_import.erl:23: :elixir_import.import/4

If you prefer the name cons instead of :: then type

defmodule KernelEx do
  defmacro cons(left, right) do
    quote do
      [unquote(left) | unquote(right)]
    end
  end
end

and do

iex(4)> import KernelEx
KernelEx
iex(5)> 1 |> cons([2,3])
[1, 2, 3]

Better than this would be to have cons out-of-the-box in the Kernel module.

12

Why make it a macro? I would say that regular function would be better and clearer, alternatively with inlining.

13

Regarding cons it can be made a function, sure, but it cannot be inlined outside the module it is defined AFAIK. Correct me if I am wrong, and Erlang / Elixir is already able to inline functions outside their defining modules.