World: r3wp

I have got a similar XYPLOT function creating an XY graph, although 
I did not release it yet

Well, how would you do the

view layout build/with [
        box 600x600 effect [
            draw [
                spider [
                    size 600x600
                    ; offset 100x100
                    pen black
                    scale 4
                    ; scale [0 150 300 450 600]
                    categories [

                        "Category 1" "Category 2" "Category 3" "Category 4"

                        "Category 5" "Category 6" "Category 7" "Category 8"
                    ]
                    directions
                    pen red
                    data [100 200 300 400 500 600 700 800]
                    pen blue
                    data [100 100 100 100 100 100 100 100]
                ]
            ]
        ]
    ] [spider: :spider*]

example without using BUILD?

Ladislav - will build be part of R3? :-)

That is why I am asking here - if there are users who will be using 
it

by looking at it, SPIDER looks like a regular function to me with 
the following block as input. I guess it can't be, because then the 
layout block could simply be done by enclosing spider [...] in ()'s 
and compose/deep the whole thing.

compose/deep - actually it could be used in this case, because I 
didn't use parens anywhere

well, just getting rid of ()'s isn't enough for me. I would want 
significant code reduction in cases where blocks would be cumbersome 
to build.

this is not about getting rid of parens, this is about *not clashing 
with parens*

With COMPOSE/DEEP you cannot use parens safely

by safely you mean selective evaluation?

yes

imagine I need parens in the layout block. Then I am getting out 
of luck with compose/deep

I can see that now. I've just not run into a case like that, I guess. 
:-)

it is not that rare to use parens in the layout block, I guess

that would be cases where you need to compose things during runtime 
and not "layout time"

another example: if you look at the SPIDER implementation, you will 
see it is implemented using BUILD too. I bet it would be much harder 
with compose, because there *are* parens in the implementation.

are you going to prepare docs for it?

I am not sure I know what to write ;-), maybe I should ask somebody 
else

well, if some good examples came into place, then I think it would 
be possible to write a little bit around it.

Well, you know I'm in favor of including BUILD in the default REBOL. 
You clash with parens all the time when building parse rules.

Brian: right, for parse rules it is much better than compose

Actually, we might use something like REDUCE/DEEP/ONLY, if the /DEEP 
refinement existed and if /ONLY specified the words that should be 
evaluated instead of the unevaluated ones

hmm, what if you have more parens, containing the same words, and 
one you want to evaluate, while second you don't?

just theoretising, not knowing what actually 'build is about ....

good question, Pekr. Answer: you can choose any new word you want 
to for the evaluation - especially some words you know you cannot 
encounter in the block are good.

For example when I use the word 'spider, I am pretty sure, it cannot 
clash with any "native" DRAW command, because spider isn't native 
DRAW command. Does that make sense?

This is exactly why COMPOSE isn't as comfortable. There are many 
blocks containing parens and you cannot pick any replacement for 
parens in COMPOSE case.

now would the only advantage to use compose be that it's a native 
function? does build make compose redundant?

yes, the only advantage of COMPOSE is, that it is native in my opinion.

would build be possible to make natively for R3?

that's what I wanted to ask about - native 'build in R3?

I am sure it is possible

then I would vote for having it done and deprecate the use of compose, 
or is that too drastic?

we may make Compose deprecated, but need to keep it for the backward 
compatibility in my opinion

or could not functionalities of both merge somehow? compose/build 
for e.g.?

yes, that is another option Carl is investigating too. We can either 
improve REDUCE (/DEEP, etc.) or COMPOSE

Compose has its uses. I don't want to go the Perl "there's more than 
one way to do it" path, but flexibilty can be useful.

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