World: r3wp

whoops, the first part didn't come along clear enough: It involves 
a bit of double work, since you need an additional variable.

the second part should have been:

a: func [animal] [
  build/words y [animal]
]

the problem with your 'animal example is, that such a thing can be 
implemented natively and be quite fast. To obtain the fastest possible 
mezzanine implementation I resorted to the "object-like" behaviour. 
BTW, it is easy to "transform":

a: func [animal /local animal*] [
	animal*: :animal
  	build/with [that is a very large animal] [animal: :animal*]
]

I support the idea of adding build as a native. I would like to check 
it out more but I think it's a good bet from what I've seen today 
and in the past.

ladislav, yes, maybe it wouldn't be a good part of build, though 
I would have liked to see such a function, at least as mezzanine.

1) I think reduce/only works backwards; /only should say what words 
you want evaluated. I don't know how much code depends on that yet, 
or if Carl would be open to change it, or even what the design rationale 
was.


I wonder if adding BUILD is will cause some confusion, because of 
similar methods to do the same thing, WRT REDUCE and COMPOSE. What 
I like about COMPOSE (and, yes, I don't like the downside of trying 
to compose in parens) is that the parens are visible, so you know 
what's being operated on. With BUILD, 'ins and 'only don't jump out 
visibly as much.

But I like the idea of a paren-friendly compose alternative, or maybe 
a refinement for COMPOSE.

we could simply add a double parens filter.  that allows parens to 
stay in the blocks, and makes the composed values even more obvious...

like so :

COMPOSE [((this)) not (that)]

with syntax highlighting, compose is VERY programmer friendly.

You can already do that as:
COMPOSE [([(this)]) not (that)]

but those extra blocks add unneeded complexity...  and honestly... 
in about 80% of cases,  the /deep refinement is required...

Or I just got that reversed, didn't I.
COMPOSE [(this) not ([(that)])]

Still awkward though.

It's awkward, I think. I can't tell what really happens when you 
embed multiple levels of parantheses and brackets

and its not of any help with /deep  I often use /deep when creating 
objects which use words which are the same as values within the code 
creating it.  same thing for dynamic view layouts.

Yeah, with /deep you have to use nested calls to compose and to-paren.

I'm all for Build. I find it very comfortable.

I think reduce/only works backwards
 - me too

 'ins and 'only don't jump out visibly as much

 - 'ins and 'only are not "real keywords". Using the /with refinement 
 you can use any keywords you like. Actually, BUILD [...] is defined 
 as:

    build/with [...] [
        ins: func [x [any-type!]] [get/any 'x]
        only: func [x [any-type!]] [
            head insert/only copy [] get/any 'x
        ]
    ]

So they are just handy defaults. I think they're as well-named as 
they can be, probably.

When constantly having to convert from one currency to another is 
it best to not use the money! datatype? If I change for Rp. to $ 
and then back to Rp. I lose a few Rp.

Is decimal! best?

that sounds like a serious flaw in the money! datatype. if it can't 
be used for financial calculations, why is it there?

It happens because there are only 2 point of precision, I think.

point = points

I'm using decimal in my money program.

about the above discussion before money, maybe a reduce/with could 
do the opposite of reduce/only.

(Skipping a lot discussions)
    build [1 [/ins 3 + 2 /ins now]]
    build [1 /only reduce [3 + 2 now]]

and i would like it. Or, because lit-wrds mean exeptions in parse, 
    build [1 ['ins 3 + 2 'ins now]]
    build [1 'only reduce [3 + 2 now]]

Money is like decimal! internally afaik.

Back to money, it seems to work fine at the console:

>> x: 9220
== 9220
>> type? x
== integer!
>> r: 777777
== 777777
>> d: to-money r / x
== $84.36
>> d * x
== $777777.00
>>

But in my script, the conversion back to Rp gives me 22.2 Rp too 
many.

What kind of mony program are you making, Anton?

Oh I've just got a very basic and customized accounting program. 
It basically just runs through all my transactions, subtracting expenditures 
and adding incomes.

It can plot a graph of the balance over the last year, so I can see 
the patterns and trends.

Is it double entry?

No, I check the balance manually occasionally.

It's really basic. What are you trying to do ?

Responding privately.

I don't understand this:

>> x: "9220"
== "9220"
>> r: "777777"
== "777777"
>> x: to-integer x
== 9220
>> r: to-money r
== $777777.00
>> d: r / x
== $84.36
>> d * x
== $777777.00
>> d * 9220
== $777777.00
>> $84.36 * 9220
== $777799.20
>> d
== $84.36
>>

What is happening there?

I had to post that before I go to sleep. I'll probably have to get 
up sometime through the night to see the answer.

BUILD - 'ins and 'only are good words, it's just that plain words, 
mixed with a lot of other plain words, don't catch your eye, so using 
any other word doesn't solve it for me. That's why I used the set-word! 
syntax in my COLLECT function if you recall. I would probably end 
up using "special" words or marker values, e.g. puting special chars 
around the words, like ~ins~ or *only*, or just using special start/end 
markers. Basically, synthesizing a paren alternative or looking for 
words that are "marked up" in a ceratin way. e.g.

    build [1 [|_ 3 + 2 _| |_ now _|]]		; |_ val _|  = ins val

    build [1 ||_ reduce [3 + 2 now] _|| ]		; ||_ val _|| - only val

    build [1 *this* and *that* but not these] 	; marked words, e.g. *-modified, 
    are reduced

Louis - what you are describing is a MOLD issue - MOLD shows you 
only two decimal digits for the MONEY! datatype

(which looks like less than you expect, doesn't it?)

on the other hand, the "full precision" is used for computing, that 
is why you see the difference

I am afraid, that you may be unable to use the current MONEY! datatype 
implementation for accounting purposes, because you probably don't 
know when you need to take care

(I don't think, you would be able to do better with DECIMAL! either 
due to the same issues)

Ladislav wrote: "you probably don't know when you need to take care." 
 You are right, but I am going to have to learn. I have written a 
double-entry fund accounting program which we are using for our non-profit 
organization for several years. I have just modified it to convert 
rupiahs to dollars. But it also has to be able to convert the dollars 
back to rupiahs properly. Are there any documents I might read to 
educate myself?

Here is samle data showing the problem:

>> d: make object! [
[        reconciled-d: "o"
[        reconciled-c: "o"
[        trans-num: "1232"
[        trans-date: 14-Oct-2006
[        check-num: ""
[        vender: ""
[        debit-fund: "GF"
[        debit-acc: "5003"
[        debit-amount: $84.36
[        debit-desc: ""
[        credit-fund: "GF"
[        credit-acc: "1001"
[        credit-amount: $84.36
[        credit-desc: ""
[        date-entered: 14-Oct-2006
[        user: "LAT"
[        rp-per-dollar: "9220"
[    ]
>> d/debit-amount
== $84.36
>> d/debit-amount * 9220
== $777799.20
>>


The result should be $777777.00, so I am getting 22.2 rupiah too 
many.

the problem you are struggling with isn't REBOL-specific