World: r3wp

;The changed build function would be:
build: func [
    {Build a block using given values}
    block [block! paren! path! lit-path! set-path!]
    /with
    values [block!]
    /local context inner
] [
    values: any [values [only: :encl ins: :dtto]]
    context: make object! values
    inner: func [block /local item item' pos result] [
        result: make :block length? :block
        parse block [
            any [
                pos: set item word! (

                    either all [item': in context item item <> 'self] [
                        change pos item'
                        set/any [item pos] do/next pos
                        insert tail :result get/any 'item
                    ] [insert tail :result item pos: next pos]
                ) :pos | set item get-word! (

                    either all [item': in context item item <> 'self] [
                        insert/only tail :result get/any item'
                    ] [insert tail :result item]
                ) | set item [

                    block! | paren! | path! | set-path! | lit-path!
                ] (
                    insert/only tail :result inner :item

                ) | set item skip (insert/only tail :result get/any 'item)
            ]
        ]
        :result
    ]
    inner :block
]

Sorry, missed one after parse ;(

thanks, incorporating your correction

http://www.fm.vslib.cz/~ladislav/rebol/build.ris now corrected according 
to the Brian's suggestion

You need to change all of the
    insert tail result
to
    insert tail :result

to keep the result from being converted from a lit-path! to a different 
path! every time.

correcting, thanks

this lit-word and lit-path behaviour does not look very natural to 
me

although insert tail result may be OK anyway?

>> result: first ['a/b]
== 'a/b
>> insert tail result 's
==
>> :result
== 'a/b/s

That means that the path! returned by DOing a lit-path! returns the 
same data rather than a copy. Interesting.

Undocumented too. I've found that lit-word! works the same way.

this is the property I called Relatives in http://www.fm.tul.cz/~ladislav/rebol/identity.html

Still, changing them would make your build dialect compatible with 
older versions of REBOL that evaluated path and paren values when 
you referenced them with a word rather than a get-word. It all depends 
on how far you value backwards compatibility.

yes, I am making the change

I remember when they changed that they said that very little REBOL 
code depended on the old behavior, and yet I had to change some of 
mine as I recall. Apparently their mileage did vary.

http://www.fm.tul.cz/~ladislav/rebol/identity.htmlposted

sorry, I mean http://www.fm.vslib.cz/~ladislav/rebol/build.rposted

I guess your Relatives are like as-binary and as-string too.

yes, that is it

(but I wrote that before AS-STRING and AS-BINARY existed), so I used 
just PARSE and DISARM to illustrate this property)

Looks good to me, although it is somewhat amusing to see SciTE's 
syntax highlighting getting confused about the word context.

ah, you are using SciTE?

(I am using PSPad, but wanted to give a try to SciTE)

Sure. I prefer Notepad++ but it doesn't have REBOL enabled as a language. 
What's with the IN patch?

in later version the IN function didn't accept any-word as argument

It seems to here, 1.3.2.3.1

sorry, I wanted to say, in older versions of interpreter

Here's a good installer for SciTE on Windows:
http://gisdeveloper.tripod.com/scite.html

I've been meaning to improve SciTE's REBOL support, but I'm waiting 
to see what changes REBOL 3 will bring.

After that I can hack Notepad++ to add the support there too.

One of your examples is wrong:
build [only reduce [3 * 4 5 + 6]] ; == [[12 11]]

testing

aha, yes, missing block brackets

example result corrected

Well, this has been fun, but I must go for now. I look forward to 
future collaborations :)

thanks

3 new entries in the blog

Henrik, good suggestion with the loop working on more than one series 
(in your reply to Carl's blog). That must be possible with a function 
definition. But it should probably be part of REBOL, at least a mezzanine.

I realized that it's not possible with FOREACH since it would need 
to know the difference between two and three blocks as input (don't 
know if a refinement would take care of that)

but I use this a lot and it would make it easier to interlace many 
blocks this way

A new mezz, formany perhaps?

I got another idea. Please see the blog.

Henrik, try to implement your ideas in REBOL code. Post it to AltME 
if you need help. Let us hash out the details, improve it. If it 
turns out well, it could become a mezzanine function.

alrighty then

Someone mentioned Ladislav's build dialect, and look what happened 
to it... ;-)

haven't even followed it, but it seems that Carl likes it

noone remembers my nforeach function? :)

I think Carl was talking about his Include. I meant Ladislav mentioning 
the build dialect yesterday in this group and me suggesting bug fixes 
immediately. It's a little better than it was before as a result. 
Sometimes it seems that the best REBOL optimizer is its community 
showing off.

explain?

Yes, demonstrate?