World: r3wp

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

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.