I am getting in this discussion very late but I think getting a change in the Erlang VM to support this would be very difficult. It would require adding a new, very specific data type and I don't see that happening. Sorry.
Robert On Tuesday, 5 July 2016 15:07:13 UTC+2, Benjamin Scherrey wrote: > > Rules regarding rounding and how to distribute the "leftovers" in > financial ledgers are critical in financial transactions and belong, > properly, in the types and operations of those types. It may be an > implementation detail that we utilize thousandths of a unit integer > representation behind the scenes but that is only a small part of the > design necessary to execute code in a financial domain effectively. > > I do agree with Onorio's comment (paraphrased) that working code speaks > louder than theory. Unfortunately I don't know enough about the language / > compiler implementation especially regarding guard types to provide such > code. My limited (and quite possibly incorrect) understanding seems to > suggest that the way I would think of doing it likely requires an upstream > change in the Erlang VM. This is the question that I am most curious about > regarding feasibility of such a type. > > - - Ben > On Jul 5, 2016 6:46 PM, "Dmitry Belyaev" <be.d...@gmail.com <javascript:>> > wrote: > >> I'm not sure that decimal type is a must. All the handling can be done on >> integers representing cents or 0.00001 of a currency or whatever is the >> required precision, and format the value as appropriate when presenting. >> That way you don't have all the complications with guards and arithmetic >> operators. >> >> On 1 July 2016 7:38:00 AM AEST, elxi...@gmail.com <javascript:> wrote: >>> >>> First of all thanks everyone the constructiveness and the great ideas. >>> I'm new to Elixir, so please forgive me if I've some bad assumptions. >>> >>> 1. Supporting number format like 1.32f or 12.45d, etc would be great >>> 2. Regarding using the regular arithmetic operators like +, -, * and >>> / for decimal type, I fail to see why it would be slower for integers >>> for >>> example. At the end I'd assume only the generated byte code matters. So >>> why >>> not generated the usual byte code when integers or floats are used and >>> generate some advanced logic when the operands are of decimal type? >>> 3. Guards, following Peter's suggestion and using some logic for >>> byte code generation (as mentioned in point #2) again I think it would >>> be >>> possible to handle decimal types transparently. >>> 4. I think simplifying a couple of things, like handling the decimal >>> types (which is a must for financial apps)/removing boiler plates, would >>> have a positive effect on language adoption as well >>> - I know it's off-topic, but it might worth mention that such >>> simplifications could do wonders, Elixir is great language but why >>> not make >>> even better out of the box, like: >>> - instead of specifying a method like this: >>> @spec add(number, number) :: number >>> def add(x, y), do: ... >>> >>> it would be far easier to write it a single line like this: >>> defs add(number x, number y) :: number, do: ... >>> - or embrace the familiar lambda syntax for defining in-line >>> functions, so that parameters could be referenced by their name, >>> instead of >>> their position >>> - etc >>> >>> >> -- >> Best wishes, >> Dmitry Belyaev >> >> -- >> You received this message because you are subscribed to the Google Groups >> "elixir-lang-core" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to elixir-lang-co...@googlegroups.com <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/elixir-lang-core/D5A1728D-A38F-4D26-A586-46D4924A5463%40gmail.com >> >> <https://groups.google.com/d/msgid/elixir-lang-core/D5A1728D-A38F-4D26-A586-46D4924A5463%40gmail.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/e26b6df7-3f8b-4392-8afd-21d69e221718%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
