World: r3wp

so, yes, it's already that wa.

way.

maybe 123kg can be made to work, but, i don't know if it would create 
problems.

that could mean some deeper changes to parser probably, no? Well, 
that is not much of an issue ....

>> 123kg
** Syntax Error: Invalid integer -- 123kg
** Near: (line 1) 123kg

syntax error means that we have a free spot in the parser there :-)

but, we should be careful with something like that, as it can get 
very confusing.

kg123 is a word for example.

we already use # in many datatypes, no? hex, binary, special notation 
of #[none], some possible binary conversion functions were suggested 
as 16#{} etc.

yes, as i said, i think only # $ and % are "special" for the parser, 
so that you have to pick there. carl picked # for a lot of things 
because $ and % carry meaning.

kg#123 and kg$123 sound equal to me. It is just that the datatype 
is called money! Dunno if english unit! term would be more descriptive/general 
...

#123 is an issue so kg#123 would mean that you always have to specify 
a unit... and a space by mistake becomes a subtle bug.

ok, so you basically just want to rename money! to unit! or something 
like that.

yes, if BCD in general would be usefull for other things than money 
and bank apps meaning, then it could be the right time to do so. 
I was inspired by dictionary! to map! rename, so it seems the team 
is open to ideas in that regard....

yes, but dictionary does not break compatibility, money! would (view 
scripts don't run in r3 but core scripts may run quite well)

I don't agree to that argument though. Even core will change, protocols, 
schemes are different, and btw - what about missing hash? I remember 
using hash, but I never used money! IMO money! is the least used 
datatype in REBOL :-)

but the issue is not really that big, so I can live with money!, 
although it will be kind of weird, if I will use it for weight or 
other unit, when the need of BCD would arise ..... well, maybe I 
will not even need BCD, so .... :-)

Petr; I use money! all the time with the contruction accounting scripts. 
 Bosses love it, until I have to pummel them for using commas in 
big money! and with construction projects it doesn't take long to 
get to a monkey.

Gabriele: Why not leave money! just as it is for compatibility for 
the people who want to use it and introduce a Fixed! type. (I didn't 
call it BCD because apparently it isn't). The following behaviour 
(modelled on IBM 360) would be ideal:

>>fixed-dec: 1.98F2
== 1.98
>>type? fixed-dec
== fixed!
>>print fixed-dec
== 1.98
>> probe fixed-dec
== 1.98F2
>>2F2 / 3F2
== 0.66
>>2F2 / 3F2 + 0.005F3
== 0.67

To keep Brian's construction bosses happy you could allow the use 
of  thousand separators eg
>>fixed-dec: 1,000F2
== 1,000.00

changing how money is implemented does not break compatibility.

also, it's not bcd, but it's not fixed point either. it is 26 decimal 
digits floating point.

why "standard" BCD aproach was not adopted? Is it binary represented 
or not? I mean - can we be sure that some weird rounding will not 
happen, and that the number stays allways the same?

I second fixed! datatype name .... or I propose unit!

I'm sure there will be notes about why standard BCD was not used.

vv.v,xc                         ,gbbokgtokio98tttttttttttttttttttttttttttttttttttttttttttttt8oolllllllllllllllk

Hi Junior! :-)

:-)

I see another rebol coder coming up

Could be a cat in the bag...

so we'll finally get regular expressions engine in R3 :-)

petr: because this the current money! format is faster and takes 
less space (you can't pack 26 bcd digits in a rebol value otherwise)

it's still decimal (not binary) so no rounding problems when converting 
from string to internal representation.

When will we be able to comment on new VID? I have found out link 
to docs. But I also don't want to open some discussion here, when 
other ppl might not be informed. The trouble is, that just because 
we are not let in in the early state of development, we might miss 
the influence on what the new VID will all be about ....

And I fear one things - it will all be cooked behind the scenes, 
and we will be presented with result. So far we were told to trust 
what the group comes up with, but I really wonder, what that group 
of 20 or so testers is doing, if docs contain things like using "-" 
char for "no value to change" meaning, instead of none :-)

I read every VID related doc more than 5 times, and I am only slowly 
starting to get the idea behind it :-) So I wonder - is new VID conceptually 
so complicated, or there is still not enough docs to get the idea? 
:-) There are already things I like a lot, but there are also some 
worries, although those migh show as minor. Maybe some better explanation 
(more docs) will help the situation ...

So far the most precise docs in View area are Cyphre's draw docs. 
Well, those are mostly a reference. I also like make-gobs doc.

The trouble is, that just because we are not let in in the early 
state of development, we might miss the influence on what the new 
VID will all be about ....


Do you really, really want that? The only thing you'll get is "design 
by commitee" and slowing things down.

whereas nowadays we get "no comment" and similar results ...

you asked at one point how much the docs correspond to the state 
of VID, and I think they are revealing probably 60-70% of what is 
there now.

From my pov, I can already see some things, which are a bit disappointing. 
I represent userbase as any other potential user. And I can already 
imagine typical answer - "you can create your own GUI after all" 
:-)

my intention is not to harm the design, but have the possibility 
to eventually influence some decisions ....

having used VID3 for a bit now, I can tell you, it's SO EASY. it's 
amazingly simple, compared to the R2 VID. it's possible to do things 
in 10 lines of code that would require 500 lines of R2 VID code.

... of course for the good ...

but it's not done yet, so we'll wait a bit longer with the comments

I hope so, Henrik - I was nicely suprised by make-gobs dialect ...., 
but some minor syntax things look just weird to me :-)

well, I expected that first comes some "basic" architecture design, 
then comes styles. Of course, when we think more complex styles, 
we just may find out, that we need to change a design, that is ok 
....

make-gob isn't even ready for commenting internally yet. I haven't 
used it, so I don't even know what it can do.

It can help you, the style designer :-)

my concerns are very simple, but concrete. I can not agree e.g., 
how stylize escapes missing arguments, from right to left, that just 
seems crazy :-)