World: r3wp

its my POV in any case.

I understand Brock's view here.  I wouldn't want to see this community 
break down and become what you find on USENET or IRC.

Feeling like I owed something back is why I started helping write 
REBOL, at least the mezzanines :)

Well, have someone answered to the mhinson's question ? 

What is the worst ?

- Having some doubts, even rude words (meaning i want to know you)
- Or apathy (do what you want, i don't care)

att: func ['paf [path!]] [any [attempt [do paf] ""]]

The worst is complaining aboput the asking of the question. The best 
is answering or trying to answer.

Apathy is fine, as long as you keep it to yourself.

>> a: context [b: 1]
>> a/b
== 1
>> 'a/b
== a/b
>> do 'a/b
== 1
>> att: func ['paf [path!]] [any [attempt [do paf] ""]]
>> att a/b
== 1
>> att a/c
== ""

Now the lit-word! argument 'paf is a little advanced - it means don't 
evaluate the actual argument. The alternative is this:
>> att: func [paf [path!]] [any [attempt [do paf] ""]]
>> att 'a/b
== 1

It's not the meaning of apathy here (check the context)

In this case, you have to pass a lit-path! as the actual argument. 
When the lit-path! 'a/b is evaluated, it converts to the path! a/b

(Temporarily going off-topic) Answering mhinson's question or asking 
some of your own is ontopic here. Telling someone to not ask questions 
is offtopic - see the group description.

Some of us like to answer questions, and learn by doing so. This 
group is like a REBOL-specific version of the Puzzles group :)

For instance, I wasn't sure that do path trick would work until I 
tried it.

Brian it was not my words. 

I never said to not respond (strange it's not your habit to perform 
false denouncements) 
And i gave a Hint.
Anyone else could have completed it at this time.


But it seems some of you guys ,like to bash for nothing using false 
reasons.
And that , it's certainly more offtopic than anyting else.

Everyone has their own way of helping ...

Let's not bash anyone please ....

Steeve just says .. "RTFM"  hahah

ooops ... didn't mean to say that.

But i gave the index lit-word! in TFM, so it was not so mean.
And i gave him my reasons.

lit-path! , i mean

Mike, by all means keep asking questions here, this is absolutely 
the right place to do so.


Conversing in plain text can be tough, and the rate at which people 
can respond here--as opposed to email--can contribute to misundertandings, 
with posts coming fast and furious. And we all interact in slightly 
different ways.

Clean slate.

Thanks Brian, I am afraid I didn't manage to solve this without your 
explicit example. "do" seems like a powerfull function that I have 
minunderstood. I have created a similar solution using lit-path! 
as well (just to learn).

mhinson has just not yet learned, how to learn a programming language. 
I've noticed that by his stumbling on every little bit of basics, 
such as lit-path and why it doesn't make sense to him, because he 
can't extrapolate how it works inside a function.

mhinson,


REBOL, like any other programming language, is a system. It's a design 
with intentions, methods and patterns and it's designer has spent 
about 25 years thinking out how REBOL should work, in order for you 
to see the elegance and simplicity of the system.


A good programmer can predict what happens in a programming language 
with a specific piece of code, not by remembering what every little 
single thing does, but by knowing how the system behaves. If you 
study the works of Ladislav (such as Bindology), you'll see how much 
time he spends on figuring out the system of REBOL. REBOL wasn't 
put together randomly. Figure out the system of REBOL and programming 
becomes way, way easier. This goes for any programming language.


It helps to, when you get to a problem, to try to figure out why 
REBOL does this and that, while you're trying to figure out how to 
solve the problem. Why do you have to pass a lit-path to a function 
for it to be understood as a path in the function?

You are right Henrik, even the programming I have done years ago 
was based on learning a set of tricks that worked in the context 
I needed, then sticking to those tricks for everything.  I can see 
that Rebol demands to be taken more seriously & I also appreciate 
the potential for "elegance and simplicity". I ride a unicycle & 
part of the appeal there is also the enjoyment of minimalism, no 
chain, no gears, no freewheel etc.


My understanding of "the system of REBOL" is about 5% I think & I 
feel like I haven't grasped enough of it yet to make my understanding 
move forward efficiently. I am just at the start of passing data 
to functions & because REBOL seems to automatically typecast a lot 
of data, it has not been in my mind that I may have to do it manually 
in some cases, but now I know that, I still can't predict which cases 
yet. 


With the lit-path! and path! data passing I understand that the invalid 
path I want to test must not be evaluated before it gets into the 
ATTEMPT section of the code, so I would expect to need to pass the 
data in a literal form I suppose (or as a string perhaps). One of 
the conclusions I am drawing from the example given is that I can 
pass this thing called a literal (I don't fully grasp what that is 
yet) but receive it in the function as a path! so it would seem that 
the passing of data to the function is also doing a type conversion.. 
At that point I don't know how the path! is not evaluated enough 
to cause an error.  If I search the core manual for "type conversion" 
it has only one mention, & not in this context. This is the sort 
of thing I do a lot to try & understand without asking too many questions, 
but my techniques must be flawed as I often fail to find anything 
relevant. (This isn't intended to be a question, just a picture of 
the muddle inside my mind).


Now I will read Bindology & hope that my understanding will be transformed. 
 Thanks again for all the help.

There are two types that get evaluated to get the value ther refer 
to and DO them: word! a and path! a/b.


If you want to just get the referred to value and not DO it you use 
get-word! :a, and in R3 get-path! :a/b, or in R2 a more complex expression 
that depends on the type of what a refers to.


If you want to set a new value you use a set-word! a: or a set-path! 
a/b: - this will evaluate as a SET expression.


If you want a literal word or path, you use a lit-word! 'a or a lit-path! 
'a/b. When a lit-word! 'a evaluates, it returns the corresponding 
word! a, not the value assigned to a. You can then pass the resulting 
word! value around, assign it to stuff, and maybe DO it later.


That lit-word! 'paf formal parameter in the first version of ATT 
that I posted blocks evaluation of the actual argument. It is treating 
the actual argument path! as a value, rather than evaluating it. 
In the second version of ATT the formal parameter is specified  with 
a regular word! paf, so the actual argument is evaluated normally. 
In order to get a path! value you have to use a lit-path! 'a/b and 
let it evaluate to get the corresponding path! a/b.

The evaluation rules follow a pretty consistent pattern, and even 
more consistent in R3. Once you get the pattern you can answer most 
of your questions yourself with a little experimentation. Don't let 
that dissuade you from asking here though :)

Thanks Brian, this is very clearly explained. so now I understand 
things like
n: 'o  probe n  probe do n  
a: 'a  probe a  probe do do do do do do do do do do a

This took me by surprise :-)  but I do understand why it happens
p: 'q  probe p  probe do p

Hi, I am reading about BIND, but I cant understand the concept of 
what it is for. Is there something I should understand first perhaps?

The function summary http://www.rebol.com/docs/words/wbind.html
description is what I am starting with, but I dont understand what 
the examples demonstrate.

being new, it probably isn't good to tackle bind just yet.  Bind 
is more advanced concepts.

'bind is used to bind a word or words to a context.

mhinson, BIND is all about contexts. A word is usually bound to a 
specific context (or object if you will), giving it a specific value 
that exists in that context. You can have:

a: make object! [
	b: 7
]

c: make object! [
	b: 9
]


'b is a word, but for 'c, it has one value and is bound to 'c's context. 
'a is a different context where 'b has different value.

So if you are in a situation where you have the unbound or incorrectly 
bound word 'b, BIND will allow you to change its context:

>> do [b]
** Script Error: b has no value
** Near: b

; no context above, so we bind:

>> do bind [b] c
== 9


This allows you also to refer to words inside a specific context 
without path notation.

mhinson, when I made Tretbase 1.0 engine, I used Bind quite a lot. 
 The only time I really like to use 'bind is when I have iterations 
where performance is an issue.   That way I could write a block of 
code and then just bind it into a logic based loop.  This way I didn't 
have to record additional loops to meet the logic.

Something more basic, that you may have skipped or forgotten: Contexts 
are just objects. They are just a clumped together set of words with 
values.

The big secret is revealed here:

>> source context
context: func [
    "Defines a unique (underived) object."
    blk [block!] "Object variables and values."
][
    make object! blk
]


So when you make a new object, you make a new context. The definition 
block (shown as blk in the source for context) is then bound to this 
new context. You can run ordinary REBOL code inside the object definition 
block. You are not restricted to the obvious syntax of set-word! 
and value pairs:

d: make object! [
	b: "hello"
	reverse b
]
d/b
== "olleh"


Of course after the definition block has been parsed to become an 
object, only the key/value pairs remain.

Remember that and you can get very far with contexts.

I think I have understood what it is that has been preventing me 
from understanding BIND.

I was expecting BIND to make a persistant difference to the contexts, 
but now I have realised that is not the case, it only acts as a function 
to return information when it is called.  That was a tough one to 
fight through.   However, now I understand Henrik's example, but 
the example in the manual still confuses me.  
words: [a b c]

    fun: func [a b c][print bind words 'a]  ;; why is this not  ... print 
    bind words 'a 'b 'c]

Does this mean that bind causes fun to be joined to the context of 
words, for all the variables used in the words context? 

I think I am also still confused about which direction the context 
moves.  Sorry to be asking again, but I do want to understand this 
completely. In Henrik's example it seems to be "do b in the context 
of c" but in the manual example it seems more like "print words (which 
in the global context ) as if the context variables of words had 
been assigned the values of the current context....  I am off to 
bed now to sleep on it.   Thanks.

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"]]]