I am implementing an application that deals with monetary values. Therefore I use the excellent Decimal library to handle such values.
Now arithmetic is supported by the various functions provided by the module, e.g. Decimal.add/2.
But this results in very hard to read and write code, take this for an example:
# I would love to write: distance = price / order_price
# But I have to write:
distance = Decimal.div(price, order_price)
# This gets even more messy when dealing with multiple values
multiplier = 0.2
sale = Decimal.add(price, Decimal.mult(price, Decimal.new(multiplier)))
So, defmacro to the rescue?
Yea, I thought I really have a clean solution with a prefix macro that deals with decimal arithmetic.
Now, in my tests writing this prefix-macro I could do this:
a = Decimal.new(1)
b = Decimal.new(2)
result = decimal a + b
assert result == Decimal.new(3)
# Tests passed, hooray!
But as soon as I used this code in my application, suddenly I got lots of (ArithmeticError) bad argument in arithmetic expression
Why is this happening? Is Elixir inlining the arithmetic expressions and therefore falling back to the Kernel defaults?
I thought I explicitly loaded the Decimal.Prefix macros in the enclosed/0 function.
The weird thing, tests pass just fine, but I don’t get why errors appear when the application runs.
And I double checked the inputs, they are all of Decimal type.
Help in this matter (also the original thing, dealing with monetary values doing arithmetic with these) is highly appreciated.
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.
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.
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.
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…
It might be necessary to deep-traverse the AST to ensure proper transformation.
