World: r3wp

http://www.fm.tul.cz/~ladislav/rebol/build.r<--- posting the source 
again for newcomers.

Has anyone implemented some kind of functional-language-style structural 
patten matching and transformation?

In theory you should be able to compile such code to parse rules...

pattern matching? do you think about improving 'parse?

All the time - haven't you been paying attention? :)

I thought parse was already being improved for R3?

I think so. I hope so, I was rather active in the discussions of 
appropriate improvements to the dialect.

Henrik - where did you get it from? :-) IIRC asking Gabriele some 
time ago the answer was something like possibly. IIRC there was one 
page with parse suggestions, but not sure what will come in. I know 
that mine would make parse a different tool, but for "novices" like 
me, I would welcome 'to [a | b | c] :-)

Brian - parse inspirations welcome, if you have got more ideas than 
the ones you already presented elsewhere

to [a | b | c] is definitely a candidate for R3

pekr, I seem to remember some discussions where Gabriele was involved. 
there was also code examples shown, but I didn't read it closely.

I don't know - I was pretty throrough before. Let me review past 
discussions and see if I've come up with anything new.

later

ladislav, what if I want to use values that are already set elsewhere, 
like function input? then the /with values block needs to specify 
the values too:

a: func [b] [
  build/with [this block contains a c] [c: :b]
]


Perhaps I've created the build block elsewhere and want to use parts 
of it with BUILD. Perhaps also I want that block to be fully readable. 
Then it would be nice to:

y: [that is a very large animal]

a: func [animal] [
  build/words [that is a very large animal] [animal]
]

a 'cow
== [that is a very large cow]

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?