Decimal arithmetic - using 'defmacro' gives me ArithmeticError

Instead of doing some juggling with the kernel import inside of a single block, you should instead transform the given block by traversing the AST:

defmacro decimal({:+, _, [a, b]}), do: quote do Decimal.add(unquote(a), unquote(b)) end
defmacro decimal({:-, _, [a, b]}), do: quote do Decimal.sub(unquote(a), unquote(b)) end
...

I’m not sure though how well this plays with more complex expressions that have more than a single argument It might be necessary to deep-traverse the AST to ensure proper transformation.

Besides of that, I think a |> Decimal.add(b) |> Decimal.div(c) reads pretty well. One has to remember that operations are applied left to right this way and one has to sort them.

Thanks, that is a good hint. I will try using the AST.
And you are right, the pipe version does not read too bad.

Also, I found after trying around and looking in the Kernel source, that when overwriting the Kernel definitions like def left + right, do: Decimal.add(left, right), instead of defining a macro, just works and does not fail when the application runs.

For reference: the updated gist.

You might like the Numbers library, which allows you to work with any numeric types, as well as automatically converting integer and float arguments to the Decimal type when the other argument is one, which removes the Decimal.new(x) clutter:

alias Numbers, as: N

distance = N.div(price, order_price)
multiplier = 0.2
sale = N.add(price, N.mult(price, multiplier))

Numbers on purpose does not export overloaded operators (but might do so in an explicit opt-in way in the near future).

EDIT: The new version 5.1.0 Has support for exporting overloaded operators as well.

For note, the reason + is not working as expected is likely because they were not exempted like via:

import Kernel, except: [+: 2]

There is only one reason to define operators as macros, which is that inside a macro you can find out if it is called as part of a guard clause, or outside of one. So outside of a guard clause you could have fancy logic, while inside a guard clause you could fall back to the built-in operators that work on the built-in data types.

Thank you all for the insightful replies. I learned a lot today.

Some time ago I wrote simple library which could help in such cases.

What happened to our favourite operator of them all?

price |> D.div(order_price)
sale = price |> D.mult(multiplier) |> D.add(price)

It’s like Reverse Polish Notation in code.

Heh, quite the interesting idea.

Actually, I am currently considering upgrading the Numeric library so that it will (when using the overload_operators: true option) switch between the built-in Kernel functionality and the overloaded functionality depending on if we are in a guard-clause or not.

Maybe providing proper error messages when doing it like that is possible as well…