World: r3wp

Personally, I've never really considered the "copy problem" a problem. 
When you don't copy something it doesn't get copied. When you do 
it does. Series aren't immediate values, they are reference values. 
Same for objects. Every language design choice could be considered 
a bug or a feature - it all depends on how you use it. I've found 
more advantages to the way that REBOL functions work now.


The only real problem I've run into is functions keeping references 
to their temporary data after they return, at least until they are 
run again (a memory hole). The closure example above with the adders 
stops being a problem when you realise that FUNC is a function that 
does something when passed a  couple blocks - it's not syntax. You 
didn't copy the block, so it gets reused, go figure. You are building 
functions - is it such a stretch to build code blocks?

make-adder: func [n] [func [x] compose [x + (n)]]

brian I agree completely.  I love REBOL's ultra consistent reference 
mechanism.  on the R3 blog, I noted how python copies everything 
and how it becomes tiring to upkeep all the time.

and for the record, I hate the fact that I have to return first reduce 
[value value: none] all the time.  its slow, ugly and its a BIG memory 
hole in view and something within the stylesheet system.

so if we now have real closures in R3 can we have real /locals in 
functions?  which explicitely remove themselves from the stack on 
function exit?

and thus get tackled by the GC?

Let's suggest that to Carl in the Closure comments.

Done.

That  return first reduce [value value: none]  is a nice trick - 
I hadn't thought of that. I did suggest on RAMBO that the unset native 
return the old value of the word it is unsetting, allowing a trick 
like  return unset value  but they haven't made that change yet.

brian: there are cases where using compose is not very convenient 
(parse, other dialects that use parens, or just because using words 
makes debugging easier if you probe the value afterwards)

I second Gabriele, words enhance readability and the COMPOSE dialect 
is not as comfortable as e.g. the BUILD dialect

I guess, that Brian didn't consider writing a more complicated asynchronous 
framework, where the advantages of closures cannot be overlooked

Build dialect?

Probably build-tag or build-markup.

Does the build dialect help with that situation where you have paraens 
inside an action block of the vid dialect, and you are using compose/deep 
on the whole layout?

L's build dialect is here .. found it after googling : http://www.fm.vslib.cz/~ladislav/rebol/build.r

Ladislav, it's not that I don't see the advantage to closures in 
principle, and that I wouldn't use them occasionally if they were 
there. It's that Carl's description of how the closures would be 
implemented seems a little heavyweight, largely as a result of REBOL's 
direct binding. I would use closures, but only when creating my own 
contexts manually or copying a subset of the data would not have 
the efficiency gains they would normally have.

I will check out your build dialect though - it sounds interesting.

I found one bug: Your build dialect will convert lit-path! to path! 
unintentionally (as far as I can tell). Convert all word references 
to block or result in your inner function to get-words (:block and 
:result respectively).

;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