r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[Rebol School] Rebol School

Henrik
10-Mar-2010
[2962x2]
no, because every time you make a new line, you are making a new 
string. in the loop, you are reusing the same string.
If you type:

>> ""
== ""


you are making a string, but you are also immediately losing it again. 
you can't use it again.

By doing this:

>> ""
== ""
>> ""
== ""

You are therefore creating two separate strings.
PatrickP61
10-Mar-2010
[2964]
Ok, so the same as the loop would be:

x: "a" append x "b"
x: "ab" append x "b"
x: "abb" append x "b"  etc    right?
Henrik
10-Mar-2010
[2965x2]
This means also that doing this:

>> x: "a"
== "a"
>> x: "a"
== "a"


you are creating two separate strings, both assigned to 'x and the 
last assignment overwrites the first one.
nope. :-)

The same would be:

x: "a"
append x "b"
append x "b"
append x "b"...
PatrickP61
10-Mar-2010
[2967]
ahhh
Henrik
10-Mar-2010
[2968]
REBOL is very aggressively reusing strings, even inside code structures.
Ladislav
10-Mar-2010
[2969x2]
or: 

    b: [x: "a" append x "b"]
    do b
    do b
    do b
you can even examine what is going on this way
PatrickP61
10-Mar-2010
[2971]
Ok, I think I got that now -- thank you all
Davide
12-Mar-2010
[2972]
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
]
Ladislav
12-Mar-2010
[2973x2]
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)
Davide
12-Mar-2010
[2975x2]
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.
Steeve
12-Mar-2010
[2977x2]
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
]
Davide
12-Mar-2010
[2979]
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)
Sunanda
13-Mar-2010
[2980]
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?
Steeve
13-Mar-2010
[2981x2]
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
Sunanda
13-Mar-2010
[2983]
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
Steeve
13-Mar-2010
[2984x2]
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
Gabriele
13-Mar-2010
[2986]
Sunanda, I don't understand how your example shows that local is 
"reserved"...
Steeve
13-Mar-2010
[2987]
Eh ! that's my line :)
Sunanda
13-Mar-2010
[2988]
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?
Steeve
13-Mar-2010
[2989]
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]]
Gregg
14-Mar-2010
[2990]
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.
Gabriele
14-Mar-2010
[2991x4]
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
Gregg
14-Mar-2010
[2995]
Gabriele, yes. My point, poorly stated, was that a *dialect* may 
have keywords, but REBOL itself does not, per Sunanda's original 
post.
BrianH
14-Mar-2010
[2996]
Or at least the DO dialect doesn't, except for one: The word 'rebol 
before the header :)
PeterWood
14-Mar-2010
[2997]
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.
Chris
15-Mar-2010
[2998]
do func [local][local] "local" - works in R2 and R3...
Ashley
15-Mar-2010
[2999]
In answer to Sunanda's question, how about 'system (in R2 it's protected, 
in R3 not).
BrianH
15-Mar-2010
[3000x5]
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.
Ladislav
15-Mar-2010
[3005x3]
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"
Sunanda
15-Mar-2010
[3008]
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
Gabriele
15-Mar-2010
[3009]
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.
BrianH
15-Mar-2010
[3010x2]
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.