World: r4wp

Carl blog about "Currency designator for money datatype" http://www.rebol.net/cgi-bin/r3blog.r?view=0201

Carl stated in its reply "4.  No, we are not renaming decimal. It 
will remain as is." just to remember us.

So:

1) current R3 money! datatype is not a money type as R2 define it. 
So it can be renamed.

2) Should the actual R3 money! be renamed decimal! is againt Carl 
point, but I'm not against it if we ponder the compatibility issue 
(BrianH point).

3) decimal! -> float!  I don't like it but  Icould probably leave 
with!

4) a money! type must be considered as a BCD + currency type. A "must 
hvae" would be the possibility to programmaticaly define the rules 
to apply if mathematical operations arrived between different currency 
numbers. So it can throw an error or apply a conversion or change 
the resulting currency...
A dialect would be used to specify the rules :

money-rules [* M M currency M²    / M M error     / M² M currency 
M       + EUR CDN error     + EUR USD multiply 1.30800]
Think ">> M$2.0 * M$2.0     == M²$4.0"

>> EUR$10 + USD$10
== EUR$23.08

I don't think people are against a money! type per se.   we are just 
against the current datatype names assigned to implementations.

decimal! is not a decimal type
money! is not a currency type


we simply need to add a new real number type called FLOAT! and  properly 
assign the current types to what they really are.


shifting the implementation of money! to decimal!  (without its $ 
or currency designation) won't actually break any previous code a 
part from making it more precise and possibly a bit slower.


we can always keep the current money! as-is, but  I see no point 
in it.  since it doesn't actually do any type of currency management.

Money has meaning, and was one of the things that really excited 
me when I found REBOL. It was also one of my biggest disappointments, 
in R2, when I found that it didn't work right. So I'm thrilled with 
the new implementation. Unfrotunately, I don't have any great suggestions 
for a float! sigil, which would allow us to identify all of them 
lexically. And I can see changing the name of decimal! to float!, 
and money! to decimal! as potentially causing problems in code that 
displays results. Suddenly all the code that explicitly casts to 
decimal! will show dollar signs.

~ is the best sigil I can think of for float!, but I don't know if 
it's better held in reserve for something else.

It's unfortunate that $ is U.S. centric, but is that a showstopper 
that requires a completely different approach, so we can support 
€. £, and more?

~ would be good for float! as it stends (for me) as an approximation 
and we know that IEEE 754 can't represent/store some decimal values.

But it is very boring to use in FR keybord as it is not displayed 
while you hit the key to allow ã or õ typing.

I can only speak for myself, but I think think float! would rarely 
be used. Mainly if you have to use routines with other languages. 
Otherwise, I would probably be OK with eliminating it entirely.

Ladislav, do you have any idea what the performance hit is for the 
new decimal implementation, versus float (current decimal! type)? 
A very quick test here was going to make me say ~30%, but division 
seems to get hit a lot harder. And I don't know how much of that 
is extra work R3 does for money, which wouldn't be there for a straight 
decimal type (if any).

I do not understand what "straight decimal type" might be.

Your new decimal implementation without the added currency/denomination 
part.

The money! implementation currently is "without the added denomination 
part"

OK, so there is no internal handling in place that would add overhead 
right now, correct? And ~30% could be a valid difference (not counting 
division).

The speed difference must be at least (actually, it should be even 
greater a bit due to the deimal nature) equal to the difference between 
floating point arithmetic done by the coprocessor, versus it being 
done by an emulator.

Just looking for ballpark estimates.

Also, division is the most demanding operation

And, let's not foget that the datatype is 96-bit, which certainly 
has to make the arithmetic slower as well.

Yes. Division makes the biggest difference by far (again, quick test).

Still probably fast enough for me. :-)

when we talk about changing the datatype names, I think we accept 
that decimal wouldn't have any currency or denominator. 

its the implementation behind the type which would be switched, and 
a "new type" added which would map to the current decimal! handling.

in fact, maybe the new float! could support NaN, +/- inf, etc    
 while decimal would continue to raise a bit more errors.

if speed is required (which it is rarely, for most cases in which 
rebol is optimal), then IMHO we won't mind dealing with any additional 
details like a type denominator (which other languages also use) 
to separate similar types like the use of   0.01f  in C/C++ to cast 
to float (instead of a double, used by default).

There is a function abs and a function absolute which seem to be 
exactly the same. Is that on purpose?

Yes, ABS is just a shortcut name, like MAX and MIN.

Does a face-to-face R2/R3 features & function comparison exists anywhere 
in the wiki?

Not that I know of. Some time back I set up a wiki on wikidot, but 
it doesn't have to be hosted there. The main idea is to have the 
data in a REBOL format so we can use it in various places. That's 
a big job, and we need to figure out how to represent comparisons. 
e.g., is R2 the baseline, and other systems could be compatible, 
extend, restrict, or just not have that functionality? 

http://rebol.wikidot.com/rebol-like-languages

I wrote a comparison, but do not know whether Robert put it somewhere 
yet

(it is not as complete as you might want iit to be, but at least 
it is a start)

Gregg, good starting point. I was looking for something like a simple 
diff version to identify the code parts needs to rewritten

and estimate the workload when migrating R2 to R3. Ladislav, will 
talk to Robert. Thanks for info.

This is a very useful project to complete.

Is there anything in R3 to deal with UTF-16 text (file) ?

I have to modify Windows File in UTF-16 with BOM of #{FFFE}. There 
were previously in ISO, but no more :-(

Basically this files are like .INI file and I have to change values 
inside with Rebol.

But  there are writen as UTF-16 on disk by the "normal" apps.

I have found that R3 is able to load my UTF16LE file correctly using 
'read/string (it "see" the BOM and transcode it to rebol string!).


Now I have to find a way to write to the file as a UTF-16 with a 
litle endian BOM format.

I think I have seen rebol code for UTF-* conversion from one to another 
format. Did I dreamed it ?

Basicaly I need UTF-8 to UTF-16LE !

Well. Don't bother. I have found another solution that just remove 
the encoding problem at the start.

DideC, the script rebxml2xml.r has support for utf-8, if that's of 
any help:
http://www.rebol.org/view-script.r?script=rebxml2xml.r

100% of voters on http://rebol.informe.compoll aske for Linux GUI

Time for some newer builds here?:

http://rebolsource.net/

Andreas says that these are mainline builds .. so depends on what 
Carl does on the main repository

Right. Builds from the community branch are still forthcoming. Unfortunately 
I didn't have as much time as I wanted during the last few weeks 
to work on this.

Carl is going to drop by the SO chat room within the next week.  
If you want to ask him any questions, you'll need a SO reputation 
greater than 20

We are thinking an IRC style conference might work .. ga

Just to clarify: Carl said it was his intention to stop by if he 
can get away from work for a bit.  I'm going to see if I can pin 
him down to a date and time.

@robert .. I made several pull requests against the R3 docs yesteday, 
see https://github.com/saphirion/documentation/pulls

Yes, thanks. I saw them. I or some of our team will check them and 
integrate them.

I hope to find some time tomorrow to look at them. Otherwise on Monday.

pair! can be floating point in R3. Is there a reason, it wasn't made 
a new datatype?

Robert, what about If someone ports those docs to REBOL Wiki ?
They would be easier to manage as DOC is not CODE.