World: r3wp

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)

And even if all functions get definitionally scoped RETURN/EXIT, 
they wouldn't become keywords at all.

A simple `return*: :return` should do the trick ...

It seems that I was quite wrong about local being a reserved word 
- it's all in how your write the function specification:


>> func-with-local-called-local: func [/local] [print local: "my 
local word"]

 >> func-with-local-called-local                                  
             
my local word

>> local

** Script Error: local has no value

** Near: local

... which also explains the "apparent" inconsistency in Sunanda's 
list of function creation mezzanines ... both funct and has always 
specify the local refinement in the funciton specification.

Ladislav, you keeep suggesting that there will be the option of dynamically 
scoped RETURN and EXIT if we switch to definitionally scoped. There 
is no indication that this is the case, and the increased complexity 
that would add to function calls is a serious indication otherwise. 
It's probably going to be only definitional or only dynamic, not 
an option of either/or. And either way we will need a workaround 
attribute: something like [throw] for dynamic, something else for 
definitional.

The word return: in the spec is compkletely unrelated to dynamically 
vs. definitionally scoped return, it is just to specify the typespec 
of the return value.

compkletely -> completely

Andreas, MAKE function! doesn't execute the code in the code block, 
it just makes the function. Your workaround applies to the code when 
it is executing. When the function is being made, the words 'return 
and 'exit will be treated specially in the function code block (if 
we go definitional for those functions), but when the code is run 
later the words are nothing special. It's similar to the situation 
with 'self and BIND or MAKE object!.

All in R3 of course.

you keeep suggesting that there will be the option of dynamically 
scoped RETURN and EXIT if we switch to definitionally scoped. There 
is no indication that this is the case

 - citation: "Allows return as a dynamic function to still work (when 
 return not in function spec.)" see http://www.rebol.com/r3/notes/errors.html

for me, it is an indication