World: r3wp

I see the bind function can do both the things I noticed above.  
I have stalled with reading Ladislav's Bindology paper at section 

9.1 I dont understand what a-word has become, and why.  I dont understand 
how 'a might be referenced in   bind 'a a-word   as it has no mention 
in the example, so I dont understand what is being demonstrated.

I think I need to work on something that is chalanging, but that 
I can do without resorting to too much guessing.

words: [a b c]					;**  words, a, b, and c belong to the global context.

fun: func [a b c][print bind words 'a]		;** 'it is asked to change 
the context of the words comprise in the block "words".

      ;** After that, they are not belonging to the global context anymore, 
      but to the context of the function.

Thanks Steeve, I think bind is becoming a bit clearer to me. Your 
comments seem to make sense to me now.

Words are immediate values, so BIND returns a new value when passed 
a word. BIND changes blocks passed to it, but BIND/copy changes a 
deep copy. The words in blocks are replaced with new words that have 
the same symbol but a different binding.

Hi, I am back to learning by guesswork I am afraid :-(    I am trying 
to do something like this
animal: "fish"  breed: "trout"
creature: reduce[to-word animal [type reduce[breed]]]
But I want the result to be 

[fish [named ["trout"]]]              what do I need to learn about 
to understand why reduce dosn't behave how I want it too please?

missing a reduce, pal

you got 3 blocks, you need 3 reduces

Thanks Steeve.  so I use 
creature: reduce[to-word animal reduce['named reduce[breed]]]

and I have to make sure I need the reduce at every level..  In that 
case why is there no reduce option to reduce all nested blocks? Am 
I doing somthing odd that would make me want that?

the alternative is compose which offers a /deep refinement:

creature: compose/deep [(to-word animal) [(named) [(breed)]]]


and all parts you wish to compose in the block must be wrapped in 
()'s.

That is very cool...  And I feel happy that I predicted there might 
be a thing that did that too... it is much more elegant than lots 
of reduce statements everywhere.  Thanks.

Compose wasn't there in the beginning ... it was a later add on because 
of these issues

Hi, I have been trying for the last hour or two to get this code 
to behave in the way I want. 
data: {
thing toy
 owner child
thing house
 owner adult
}

thing: copy []
owner: copy []
StructuredData: copy []

parse/all data [ 
	any [

  ["thing " copy thing to newline (append StructuredData reduce[to-word 
  thing[]])]

  |[" owner " copy owner to newline (append StructuredData/(to-word 
  thing) compose/deep [owner[(owner)]])]
		| skip
	]
]
probe StructuredData

[toy [owner ["child"] owner ["adult"]] house [owner ["child"] owner 
["adult"]]]


My problem is that the toy & the house are owned by the child & the 
adult. It seems the things are linked to each other in a way I dont 
follow.  If I assign the values directly, rather than using the parse, 
then the StructuredData contains what I expect.
[toy [owner ["child"]] house [ owner ["adult"]]]

Just realised if I dont go to bed now the birds will start singing 
& the sun will be comming up again.. Rebol seems to cause time to 
speed up :-)

Your problem is this line:


 ["thing " copy thing to newline (append StructuredData reduce [to-word 
 thing []])]

Specifically this part:

	reduce [to-word thing []]


The last block here is never copied.  When you append your data with 
the reduced block, the owners block is always the same (as in 'same?) 
block.  You need to create a new block each time:

	reduce [to-word thing copy []]
or
	reduce [to-word thing make block! 5] ; 5 is arbitrary

Thanks Chris.  There are several things I have learnt from this: 
 COPY has more varied use than I was aware of. In this case I think 
COPY is making sure I am adding a unique empty block, rather than 
a link to this one.


I still cant quite get my head round an empty block being something 
that can be referenced again later, although I know I have read about 
it previously & know it is important.

Why do I not seem to need COPY in my following example?
StructuredData: copy []
thing: copy "toy"
append StructuredData reduce[to-word thing[]]
owner: copy "child"

append StructuredData/(to-word thing) compose/deep [owner[(owner)]]

thing: copy "house"
append StructuredData reduce[to-word thing[]]
owner: copy "adult"

append StructuredData/(to-word thing) compose/deep [owner[(owner)]]

probe StructuredData
[toy [owner ["child"]] house [owner ["adult"]]]

You only need to copy if you use it more than once.

It happens because the outer block [to-word thing []] is referencing 
the inner block

mh: In the case above, when you were using 'reduce, you were evaluating 
the first block, in which the second block is just a value.  When 
you evaluate a block value, it is not in turn evaluated:

	>> [i'm not code]
	== [i'm not code]

It's important to remember when you do some deeper evaluation:

	>> code: [[]]  ; block containing a block value
	== [[]]
	>> append code/1 'a  ; modify block value
	== [a]

 >> result: do code  ; evaluate block, block value returned - now 
 referenced by 'result
	== [a]
	>> append code/1 'b  ; modify block value
	== [a b]
	>> result  ; result is referencing the same value
	== [a b]
	>> append result 'c
	== [a b c]
	>> code
	== [[a b c]]


Every value in REBOL is merely referenced to by the language.  Sometimes 
explicitly:

	result: []
	probe result

Or not:

	code: [[]]
	probe code/1

Or both:

	code: [[]]
	result: code/1
	probe same? code/1 result

Thanks Chris, Graham, Izkata   I feel like I half get this, but not 
well enough to be confident yet. I have been trying to create a really 
simple example where two parts of the same block are really the same 
items, so changing either, changes both because I think it will help 
me understand better & that was the behaviour in my original example. 
 Perhaps if I study this for another couple of hours I will get a 
breakthrough with it.  Thanks.

Such as?:

	>> attr: []
	== []
	>> cont: reduce [attr attr]
	== [[] []]
	>> insert attr 'c
	== []
	>> insert first cont 'b
	== [c]
	>> insert second cont 'a
	== [b c]
	>> cont
	== [[a b c] [a b c]]

Note that you can continue to reduce the 'cont block, yet the two 
values remain the same.

Hi Chris, I am slowly getting there I think.  Thanks for additional 
example.

Try this:  Predict the output of these function calls:
foo: func [/local A B][
   A: []
   B: copy []
   print mold append A {a}
   print mold append B {b}
]
foo
foo
foo

;Thanks Izkata, I predicted the outcome correctly. I went on to try 
this:
D: [{bar}]                                        ;; global D
foo1: func [D][D: [] print mold append D {d}]     ;; 
foo2: func [D][D: [] print mold append D {d}]     ;; 
foo1 D  ;; value of global D passed to function (but not used)

foo1 D  ;; function references its own local value of [] to which 
it keep appending {d}
foo2 D  ;; same as foo1 but references its own [] ?pointer? thing
D       ;; still references un changed global D

foo1: func [D][D: [] print mold append D {d}]   ;; rewriting foo1 

foo1 D                                          ;; new foo1 function 
has new [] pointer

foo3: func [][D: [] print mold append D {d}]    ;; D is not passed 
to the function

Foo3          ;; now we are changing global D and making it reference 
foo3 [] pointer 
D             ;; proof global D has changed

;; I think the bit that was making it hard for me to understand was 
that 

;; referencing the same empty block in a function means the actual 
exact function, 

;; a second copy of it even with the same name, sets up a new local 
pointer. And also the unexpected localness confused me.


;; Question, do my comments show that my understanding is now correct 
please?

It looks correct to me

:-) thanks Izkata.. I may be moving forward at last :-)

What is the length limit for a comment line please?  some of my comment 
lines are being intrepreted.  I think it is the length of them.

I'm not aware of any limit.

Are you doing this?

comment {
	mutliple comments?

}

no, just ;; in front of a few very long lines.

well.. as I said, not aware of any limit.  maybe it's your editor?

it is like that because I have a bunch of lines that will become 
a function & I am comparing them in some cases, and excludeing them 
in other cases to debug my code.

well, use 'command { }

comment

;; ownerRule: ["owner "  copy owner to newline  

;; ((if (error? try [StructuredData/(to-word thing)/owner]) [append 
StructuredData/:thing reduce[owner copy[]]])(append StructuredData/(to-word 
thing)/owner compose/deep [(owner)]))

;; ownerRule:   ["owner "  copy owner to newline  (append StructuredData/(to-word 
thing) compose/deep [owner  [(owner)]])]

The comment thing sounds good... I will use that instead.  Thanks.

and you only need a single ;

;; is redundant

Those lines I posted still do strange stuff with a single ;  at the 
beginning.  Could it be a bug with the console?  I do 2 ;; to make 
them stand out more, although syntax highliting does that already. 
Thanks.

when using the console, always use:
 do clipboard://

Thanks, that avoids the anomolie :-)

A tip I picked up off of the Mailing List years ago (thanks to whoever 
it was)
   doc: does [do clipboard]
then you need to just type
  doc
to
  DO Clipboard://

Opps -- one line of code, and 100% of it is in error:-(
  doc: does [do clipboard://]

I put this in my %user.r

paste: does [do clipboard://]

I hace CC to write clipboard://, and load-clip and read-clip as well. 
Very handy.

I also have CDR for change-dir+to-rebol-file.

Hi, is thre a neater way to do this please an avoid so many reduce 
statements please?
QQ: []

func1: func [o1] [append QQ copy/deep reduce [reduce o1 reduce reduce 
[reduce o1]]]
owner: "Luke" 
func1 'owner
[owner ["Luke"]]

func1: func [o1][append QQ compose/deep [(o1) [(get :o1)]]

missing close bracket