World: r3wp

I'm not defending it, just trying to come up with a theory.

... but yes, REBOL is dynamic, so it might be a problem, to have 
all cases working as expected ...

lol

because I know that Carl works alot more with cases of usage rather 
than theoretical correctness, as long as the result isn't completely 
backwards/illogical.

Well, at least I know how to get around it which is why I just mentioned 
that it "bothers me".

Now someone clever should answer, if it would have some consequences 
to not reduce lit-word upon block insertion?

But to me Henrik the append or insert should be able to look at the 
argument and see it is already a lit-word and append it as such.

I was going to write something clever about that, but I think trying 
to fit such a change in has some pretty big ramifications for how 
words are used in REBOL. :-)

anyhoo, I can't defend it, so I'll let BrianH take over.

Heh.

Well at least you didn't try to give excuses.

Thanks Henrik.

It's not the insert that changes the litword to a word, it is the 
initial evaluation of the litword. By the time insert sees it it's 
already a word.

But couldn't insert be modified to see that it is appending a lit 
word to a block and make the appropriate modification?

INSERT wasn't appending a lit-word, it was appending a word. DO converted 
the lit-word to a word, not INSERT.

In the example, I gave I showed that b was a lit-word being appended 
to a.

well at least in my understanding of it.

But I already get the idea.  That the idea is that it it is now a 
word and  not a lit-word!

No, it was an expression of the words append and a and a lit-word 
'b. DO evaluated the expression, and while doing so evaluated the 
'b to create b. Then it passed the b to the function referenced by 
the word append.

Back to this issue, I checked replace and it doesn't support replacing 
word! in a block with lit-words.

Code? A lit-word is an active value, like a function. You need to 
use get-word references if they are assigned to variables, or to-lit-word 
if they are literal in a place where they will be evaluated.

I'm moving on from that issue.  I'll wait and consider R3.  But these 
pitfalls have already got me into other languages.

R3 is no different from R2 when it comes to lit-words. REPLACE is 
the same in both too.

Yeah was figuring that would be the case.

That's funny, other languages' pitfalls get me more into REBOL.

REPLACE is safe for active values, so it definitely will allow you 
to replace words with lit-words, as long as you actually pass it 
lit-words.

This is true for R3 and 2.7.6+ at least.

Not an issue really.  Good think about REBOL is you can usually find 
a workaround.

I just noticed this group is web-public.  Shouldn't this be a bit 
more closed as often bugs and such are discussed here.

Given RAMBO, the R2 bug database, is web available it should not 
be too much of a problem:
http://www.rebol.net/cgi-bin/rambo.r

I think what Brian is saying is that it isn't a bug issue.  Just 
a gotcha.

I make it a point to not discuss bugs with security implications 
in web-public groups. Otherwise it is better to let people know.

BACKPORTS! Hot off the presses! Get your new R3 functions, now here 
for R2! Available now, before the next release!

funct: make function! [
    [catch]
    "Defines a user function assuming all set-words are locals."

    spec [block!] "Help string (opt) followed by arg words (and opt type 
    and string)"
    body [block!] "The body block of the function"
    /local r ws wb a
][
    spec: copy/deep spec
    body: copy/deep body
    ws: make block! length? spec
    parse spec [any [

        set a [word! | refinement!] (insert tail ws to-word a) | skip
    ]]
    wb: copy ws
    parse body r: [any [
        set a set-word! (
            unless find wb a: to-word a [insert tail wb a]
        ) |
        hash! | into r | skip
    ]]
    unless empty? wb: difference ws wb [
        remove find wb 'local
        unless find spec /local [insert tail spec /local]
        insert tail spec wb
    ]
    throw-on-error [make function! spec body]
]

functor: make function! [
    [catch]

    "Defines a user function with all set-words collected into a persistent 
    object (self)."

    spec [block!] "Help string (opt) followed by arg words (and opt type 
    and string)"
    body [block!] "The body block of the function"
    /local r wb a

][ ; Note: Words in the spec override the bindings of the object 
words.
    wb: copy []
    parse body r: [any [
        set a set-word! (unless find wb a [insert tail wb a]) |
        hash! | into r | skip
    ]]
    remove find wb [self:]

    throw-on-error [make function! copy/deep spec  bind/copy body construct 
    wb]
]

Obviously the R3 versions are faster, smaller and more efficient, 
but the meaning is the same. And you can use them now in R2.

The first, FUNCT, implements Ruby-style local variables without any 
explicit declaration needed. The second implements static locals.

we need FUNCTARD which converts all words in locals.

(joke)

*TARD indeed, because such a function wouldn't be able to call external 
functions, not even DO :)

ahah...

arghhh... rebdev is bugging.... Carl what have you done !!!!???? 
:-)

It might interest you to know that all event handlers in the R3 GUI 
are created with the R3 version of FUNCT.

event handlers are my next assignement i have some new ideas too

They are declared as code blocks in R3, not functions, and then turned 
into functions using a fixed spec and FUNCT. Safer that way.

like actors in scheme i begin to know well that behavior

btw, i know some optimisations on the make-port intrinsic function, 
it's an old one currently

humm... what i said is not clear

Static locals.  I love it.

R3 has changed SET to allow [set-word:] arguments so that they can 
be used with functions like FUNCT and FUNCTOR. R2 not (yet?).

Cool functions Brian.

Yeah, I wrote them this evening (with helpful criticism from Steeve. 
I also wrote the R3 version of FUNCTOR.