<div dir="auto"></div><div class="gmail_extra"><br><div class="gmail_quote">On 4 Apr 2017 13:57, "David Turner" <<a href="mailto:dct25-561bs@mythic-beasts.com">dct25-561bs@mythic-beasts.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">It's the currency conversions that will provide the most interesting challenges in that list. If you were only working in a single currency then something based on `Integer` would, I think, be fine. Perhaps `Int` or `Int64` if you needed the extra speed.<div dir="auto"><br></div><div dir="auto">There are a number of different ways to implement multiple currencies depending on your desired semantics and applicable accounting rules and regulations. Peter Selinger has a good tutorial covering this at <a href="http://www.mathstat.dal.ca/~selinger/accounting/tutorial.html" target="_blank">http://www.mathstat.dal.ca/<wbr>~selinger/accounting/tutorial.<wbr>html</a></div><div dir="auto"><br></div><div dir="auto">One thing to watch out for: do you want to be able to do arithmetic on amounts from different currencies? As in, do you want £5 + <span class="m_-8273422182899038522money">$5</span> to have a meaningful result? If you can avoid this, life will be much simpler.</div><div dir="auto"><br></div><div dir="auto"><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 4 Apr 2017 12:22, "Saurabh Nanda" <<a href="mailto:saurabhnanda@gmail.com" target="_blank">saurabhnanda@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi Manuel,</div><div><br></div><div>Thank you for your reply. Some clarifications below...</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px">It depends on what sort of computation you'll be doing upon those<br></span><span style="font-size:12.8px">monetary values and on the expectations of your users.  It's typical<br></span><span style="font-size:12.8px">that payment processing applications sacrifice precision and instead<br></span><span style="font-size:12.8px">prefer to deal in exact quantities</span></blockquote><div class="gmail_extra"><br></div><div class="gmail_extra">Is there a document which explains common use-cases for monetary values and best-practices for dealing with them? Any guidelines for which **Haskell** data-types to use for what kind of monetary calculations? </div><div class="gmail_extra"><br></div><div class="gmail_extra">Here is what we are doing in our app:</div><div class="gmail_extra"><br></div><div class="gmail_extra">* Powering web-based e-commerce checkout flows</div><div class="gmail_extra">* Allowing store owners to input tax rates</div><div class="gmail_extra">* Allowing end-customers to see product prices in different currencies (so, currency conversion)</div><div class="gmail_extra">* Various reports to see total sales, total receivables, and total payables (basically a **very** small subset of small-business accounting)</div><div class="gmail_extra">* Exporting data to full-fledged accounting systems, like Quickbooks and Xero.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Based on this use-case, which Haskell data-type would you suggest?</div><div class="gmail_extra"><br></div><div class="gmail_extra">-- Saurabh.<br><div class="gmail_quote"><br></div>
</div></div>
<br>______________________________<wbr>_________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bi<wbr>n/mailman/listinfo/haskell-caf<wbr>e</a><br>
Only members subscribed via the mailman list are allowed to post.<br></blockquote></div></div>
</blockquote></div></div>