World: r3wp

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

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)]