World: r3wp

ahhh

REBOL is very aggressively reusing strings, even inside code structures.

or: 

    b: [x: "a" append x "b"]
    do b
    do b
    do b

you can even examine what is going on this way

Ok, I think I got that now -- thank you all

I need a small function "my-compose" that takes a blocks, deep search 
tag! values and change it with the value of the word into the tag.
For example, if I have a test function like this:

x: 1
test: func [y /local z] [
	z: 3
	my-compose [ 
		print [ <x> + (<y> + <z>)]
	]
]

Calling:

test 2 

should return:

>> [print 1 + (2 + 3)]

My problem is to do the right bind in the parse:

my-compose: function [code [block!]] [elem rule pos] [
	rule: [any [

  pos: set elem tag! (change/only pos **magical-bind-here** to word! 
  to string! elem ) |		    	
		pos: any-block! :pos into rule |
		skip
	]]
	parse code rule
]

for inspiration, check http://www.fm.tul.cz/~ladislav/rebol/build.r

(you can even use it directly, if you don't insist to use just tags)

but in "build" you have to use the /with refinement ,  passing the 
block with the couples word-value isn't it ?

Now I'm using this function: 


my-compose: function [code [block!] params [block!]] [elem rule pos 
temp] [
	rule: [any [

  pos: set elem tag! (temp: select params to word! to string! elem 
  if not none? temp [change/only pos temp]) |		    	
		pos: any-block! :pos into rule |
		skip
	]]
	parse code rule    
]

And I call it using:

my-compose [print <x> + (<y> + <z>)] reduce ['x x 'y y 'z z]


It works but the second block is redundant and I would eliminate 
it.

you need to pass the values to map because the formula block only 
contains tag! which basically are strings (tags have no context, 
nor values).
if instead you use get-words as tags, you don't need to.

my-compose: func [code [block!] /local pos][
	parse code rule: [
		any [
			  to get-word! pos: (pos/1: get pos/1) skip 		    	
			| to any-block! into rule
		]
	]
	code
]

>>x: 1
>>y: 2
>>z: 3
>>my-compose [print :x + (:y + :z)]
==[print 1 + (2 + 3)]

Correction:

my-compose: func [code [block!] /local pos][
	parse code rule: [
		any [
			  pos: get-word! (pos/1: get pos/1)
			| into rule
			| skip
		]
	]
	code
]

Steeve thanks, now it is much more clear.

I'll use the get-word type as you suggest. (I have to change a bit 
my dialect, but it's not a problem)

REBOL has no reserved words
 --I've seen suggestions like this several times.

There are exceptions....Some of the commonly used dialects have many 
reserved words. [Parse, View etc]. That is clearly stated in some 
of the documentation, eg:
    http://www.rebol.com/docs/view-guide.html#section-7


In addition, 'local acts as a reserved word as this code (R2 or R3) 
shows:
    >> use [local x][x: has [local][]]
    ** Script Error: Duplicate function value: local


So there is at least one real reserved word. Anyone know of any others?

it fail not because it's reserverd, but because you declare local 
twice.
what you do is:
>>func [/local local][]

i give you a true one in R3.
>> context [self: 1]
** Script error: cannot set self - it is protected

I see where you are coming from. But I explicitly used USE [LOCAL] 
to make LOCAL local to my block.

If FUNC has a problem with that, it helps establish my point that 
LOCAL is a de facto reserved word.

Good one with SELF

It doesn't matter where you declared local at first, make function! 
rebound all the parameter in its own context

See, local is not reserved in functions, just don't use /local

>> local: 1 do does [probe local]
==1

Sunanda, I don't understand how your example shows that local is 
"reserved"...

Eh ! that's my line :)

Try this:

     loca: 88 use [loca x][loca: 99 x: has [loca][print loca] x print 
     loca] print loca
I'd think we'd agree that should print 3 lines:
    none
    99
    88

Now, replace 'loca throughout with 'local. Does it do the same? If 
not, how can I change the code so it does?

As I tried to say, the issue comes from how HAS declares locals.


If you use this version instead, you don't have the problem anymore.

has: funco [spec blody][make function! reduce [unique head insert 
copy/deep vars /local copy/deep body]]

You made the point in your initial post Sunanda: "Some of the commonly 
used dialects have many reserved words."  Function specs are just 
a dialect. A reserved word, or keyword, is one that can't be used 
for your own purposes because the language has a fixed requirement 
for its use.

Gregg, but that's not even the issue here. Sunanda, did you try to 
SOURCE HAS ?

>> local: 88 use [local x] [local: 99 x: func [/local] [print local] 
x print local] print local
none
99
88

/local is NOT treated in any way differently than any other refinement.

>> f: func [/local x] [print [local x]]
>> f
none none
>> f/local 1
true 1

Gabriele, yes. My point, poorly stated, was that a *dialect* may 
have keywords, but REBOL itself does not, per Sunanda's original 
post.

Or at least the DO dialect doesn't, except for one: The word 'rebol 
before the header :)

It seems that it is not possible to use the word 'local as a word 
in the context of a function. (R3 raises a dupilcate word script 
error if you try.)  So in that sense 'local is a reserved word in 
any function.

So it would appear to be a reserved word at least.

do func [local][local] "local" - works in R2 and R3...

In answer to Sunanda's question, how about 'system (in R2 it's protected, 
in R3 not).

The only keyword in R3's DO dialect is 'rebol, but it is not reserved 
and you can use it elsewhere. However, many words are predefined 
and some are protected - this doesn't make them keywords though. 
Many of the built-in functions and dialects have keywords though.

The HELP function treats the /local refinement specially in function 
specs, but the function spec dialect doesn't: /local is just another 
refinement. Some of the mezzanine function creators treat /local 
the same way HELP does (particularly HAS, FUNCT and FUNCTION), but 
that's just a convention, not a reservation. The duplicate word error 
PeterWood got above would happen if any argument word was duplicated, 
not just 'local.

R2's function spec dialect has keywords: The attributes [throw] and 
[catch] and the type names in the type spec blocks. R3's function 
spec dialect doesn't currently have keywords, even those that R2 
has; you can use any type name you like. Eventually R3 will have 
set-word function attributes and they will likely be keywords, though 
you'll probably still be able to use the same words as arguments 
or types if you like since those aren't expressed with set-words.

Strangely enough, the BIND function has a keyword that DO doesn't: 
'self.

The 'system word is predefined and protected, but not a keyword in 
any built-in dialect in R2 or R3.

Strangely enough, the BIND function has a keyword that DO doesn't: 
'self.

 - as far as I know, 'self is not a keyword for Bind in R2, but it 
 is a keyword of the object spec dialect.

The Do dialect in R2 has keywords: all infix op words (+ - * / ** 
= <> ...) are treated as keywords in R2.

...the DO dialect doesn't, except for one: The word 'rebol before 
the header

 - actually, I would say, that the word 'rebol is a keyword of the 
 script specification dialect (i.e. I would make a distinction between 
 "plain Do dialect" and "script specification dialect (s)", there 
 actually are two variants of the script spec dialect, one for "normal 
 script", one for "embedded"script"

Thanks for the various explanations and examples.


My conclusion.....At the very least. use of LOCAL as a variable should 
be flagged somewhere as a potential gotcha. 


Consider the six R3 functions below. Some print NONE, some print 
999 -- not every developer will have enough guru-fu to know which 
do what:

local: 999
 f: closure [] [print local] f
 f: does [print local] f
 f: func [][print local] f
 f: funco [][print local] f
 f: funct [][print local] f
 f: has [] [print local] f

Sunanda, more than guru-fu, people just need to use SOURCE. :-) BTW, 
we could change /local to /some_unlikely_to_be_used_word, it's just 
a mezz change.

Right, Ladislav, I forgot to mention that it is R3's BIND that has 
the 'self keyword.

In R2 DO of a block or string didn't require (or use) the header, 
but DO of a script does. In R3 it's the same for DO of a block, but 
strings are treated like scripts now, and the header is optional, 
unless you need information in it. So DO script has a 'rebol keyword, 
but DO block doesn't. And DO block is what we think of as being the 
DO dialect.

Sunanda, I actually use 'local in some functions as a extra temporary 
variable. It has a good name for that use.

Ladislav, good catch on the op keywords in R2 :)

Btw, if RETURN and EXIT go definitional in R3, 'return and 'exit 
will effectively become keywords in functions.

Certainly not in all functions, if I understood Carl well, he seems 
to plan to have two types of functions:
- functions with dynamic Return
- functions with definitionally scoped Return

(and the word return: in the spec seems to be the discerning indicator)