In R3, we do not yet support this format.
I'm polling the group to see if you want this feature supported.
To access the currency field we would add a new selector that would return the currency as a word:
Of course, it's just a "label change". No exchange rate conversion is done. You would need to code such methods yourself.
Henrik
14-May-2009 13:52:17 |
That page reads "Last updated: 12-Nov-2008"
The question is how often that list is updated and if you want to ship REBOL 3 with standards lists that easily outdate. If it's too often, I'd rather support a WHATEVER$100.00 method and just let us fill the currency list on our own. |
Brian Hawley
14-May-2009 14:00:37 |
Henrik, think of the space involved.
Money is an immediate type, which means that the information in it has to fit in a value slot. If the currency designator is a pointer to a word, that pointer has to go somewhere. The space it takes up has to come from somewhere.
The advantage to using a byte code is that it would only take a byte of space, leaving more room for the numeric portion of the value. This means more digits in our money. |
-pekr-
14-May-2009 14:08:01 |
I don't know how others, but for me money datatype is the most useless datatype REBOL ever had. I can't imagine using its relative advantage of not allowing to do math with two different types (e.g. USD$10 + CZK$10), because that is REBOL only format and no other external DB storage supports it. What is even worse for me is, that BCD is represented by such a weird name - money! |
Robert
14-May-2009 14:26:51 |
Petr, well in R2 I agree, in R3 it's one of the most USEFULL additions for me.
So, yes, supporting different currencies makes a lot of sense. And 254 seems enough to cover all major ones. |
Steeve
14-May-2009 14:27:16 |
To my mind we need a more generic way to define values wich have an stored-as representation and a displayed-as representation.
Their definition, could be handled within an object.
make computed! [
currency: 'EUR
stored-as: $100.00
displayed-as: does [format [[currency stored-as]]
]
Then, setting or getting actions on such objects (with no refinement) should deal with the stored-as value.
But when the object is printed, molded (But molded/all should return the whole object), it's the external representation which would be used.
The advantage there, is that we could easly change the external representation depending of the country rules.
Think about it, it's not limited to currencies use cases.
|
Henrik
14-May-2009 14:29:32 |
Pekr, don't forget why we have many datatypes. Leaving money! out means making dialects involving numbers that are money, becomes harder to do. In fact: Bring in more datatypes. I would like to see some datatype that represents physics units. More dialects for scientists.
I do agree that using BCD with money! only, is a weird way to do BCD. |
-pekr-
14-May-2009 14:32:36 |
Henrik,
I just thought about the name change, e.g. decimal! (we have now), then float!, bcd!, precise!, but really not sure about the money! name. OTOH you are right that without special sign we could not easily distinguis it in dialects ... |
-pekr-
14-May-2009 14:40:09 |
I probably agree with Max on AltME remark - we should have money!, decimal! should be renamed to float!, and there should be new decimal! for clean BCD purposes ... |
Carl Sassenrath
14-May-2009 15:02:57 |
There are multiple discussions here. So, here are mulitple replies:
- You should consider the $ just as a notation that means APM (arbitrary precision math). It is a lexical notation to separate it from decimal (FPM). We could have used some other notation, but the lexicon does not have many left.
- Pekr, APM is very useful. (I think you need to chat with and perhaps buy a beer for our friend Ladislav from time to time. And, I will also do so when I visit Prague someday.)
- Currency lists could be dynamic, with any ASCII three-letter symbol allowed. The limit would be 255 currency symbols.
- No, we are not renaming decimal. It will remain as is.
- Steeve, your suggestion goes far beyond just this topic. It needs its own discussion. But, be sure to consider the load time for REBOL data. Speed is critical.
|
Brian Hawley
14-May-2009 15:25:32 |
As long as the line format for money! has the three-letter code, the in-memory format could have a byte, with the mapping being constructed dynamically as new three-letter codes are seen. The zeroth code (0 of 0-255) can be no prefix at all. It could be about as fast as a static map. |
-pekr-
14-May-2009 15:47:33 |
Carl, I have nothing about APM, I just think that calling that concept money! is not correct, that is all ... |
FvA
14-May-2009 17:37:41 |
My 2 cents: I think APM is just that, it has nothing to do with money. Actually money arithmetic is just a subset of APM. It would be nice for computations to default to APM when appropriate. It is unsatisfying to get an overflow error when, e.g., we multiply 2 "long" integers.
|
Ladislav
14-May-2009 17:45:19 |
Currency symbols may further enhance readability of REBOL for humans as well as improve dialecting possibilities. Taking that into account, I support currency symbols.
There is one issue, though. Should we allow or disallow some arithmetic operations, like (USD$100 + CAD$15) or (USD$10 * USD$11)? If not, then we certainly need a special variant (called No-currency, or XXX at http://en.wikipedia.org/wiki/ISO_4217), capable of all arithmetic operations like (XXX$11 * XXX$10) or (XXX$13 / XXX$10) and allowed as a divisor or multiplicator for any other currency (like XXX$5 * USD$10 == USD$50). |
Sunanda
15-May-2009 2:35:50 |
Much as I like compatibility with R2....
Maintaining a 255x3char list of currency ids (or even setting up the initial list) is not a core task for a language designer, or for RT.
And it would not export/import well between different systems where the list of TLCI (three letter currency ids) where different:
load "LID$3.4" ;; Linden in-world dollars
;; for a system that is using
;; fantasy game currencies
But it would be good to have ways of distinguishing different currencies within a system.
So why not allow a currency designator that is numeric, 000-255?
amount: 2$3.4
We'd all have to have our own list of what ids are which currencies:
pick ["eur" "usd" "cad"] amount/currency
And we'd have to be careful about data interchange. But both those conditions apply anyway.
|
Peter Wood
15-May-2009 3:34:35 |
I don't think that having a currency designation serves any really useful purpose. It's pure "source candy".
If somebody has to seriously deal with multi-currency applications they would most probably need to store other data such as the value of the amount in the system's base currency.
Surely, it's easy enough to use an object! to achieve the same effect.
If people are desperate for a datatype that includes a currency designator then surely they can create a user-defined datatype as I have been advised to do for an XML datatype.
|
Menthy
15-May-2009 11:26:01 |
It wouldn't be pure "source candy" if there was more functionality included in the idea.
Like preventing operations that involve different currencies (unless one or both are converted to the same currency and datatype/precision).
If it's done like that, why stop at currencies, and not include other (non-)SI units ? Just provide the basic framework, and let conversions be defined by the programmer. |
Ladislav
15-May-2009 12:55:49 |
re currency list: "Maintaining a 255x3char list of currency ids (or even setting up the initial list) is not a core task for a language designer, or for RT. " - indeed, it looks like a task for the GC. |
Brian Hawley
16-May-2009 14:04:16 |
Sunanda, Ladislav, if the mapping from 3-letter codes to bytes is done dynamically on load, as I suggested earlier, then RT won't have to maintain any list.
All that is required is that the line formats - REBOL syntax and Rebin - include the 3-letter code instead of the in-memory byte. That is a simple matter of mapping back to the 3-letter code on MOLD. |
Ladislav
19-May-2009 15:28:31 |
Yes, Brian, it may be even possible to use the GC to free code table positions that are not used anymore (hence "the task for the GC") |
Rob Lancaster
21-May-2009 18:54:50 |
My NZD$.02
Operations like:
ADD USD$100 NZD$100
Should not be allowed - because the results are meaningless.
In the future a language may also have other datatypes, such as GPS co-ordinates.
GPS co-ordinates can be represented on different Datums. Mathmatical operations that use different DATUMS (or Map Grids) can produce meaningless results.
It's like mixing metric and imperial units...
Maybe parts of the this Money! discussion fit into a more generic use case: For operations involving like-but-unlike types.
Cheers.
|
Henrik
22-May-2009 3:40:19 |
I don't agree that it doesn't make sense. There needs to be a way to perform easy exchange rate conversions and without math functions, we need to convert to decimals, in which we will lose BSD precision.
Make rules on the outcome. If you try ADD USD$100 NZD$100 on Google, it works perfectly fine and as I expected, the result is converted to USD, so that's a good rule to use.
The hard part is to provide a conversion table that can be updated on the fly, and is depending on an online service. This is something that's never been a part of REBOL before.
It makes me also ask if there would be a general money designator, one without numbers, or if we can just use a word.
For physical units like imperial vs. meter, that's why I have talked about physical units as a datatype, again something that REBOL can be aware of, so it's easier to build conversion tables. More complex symbolic unit calculations would be a separate module made by one of us, maybe as a part of symbolic math module. |
Chris
27-Aug-2009 22:33:42 |
My belated $0.02 - if it's possible to maintain R2 arbitrary currency codes, that'd be my preference. Do not allow mixed currency operations, and leave any conversion to the developer with some pointers to services that publish conversion rates. |
You can post a comment here. Keep it on-topic.
