World: r3wp

SYMBOL! is internal houskeeping for names of words (?) and a routine! 
is for working with a call to a DLL  ( of my 54 datatypes in a 2.6.3 
VIEW exec )

Robert  you can get a similar list by doing

? !

or using   "? datatype!"

not as much fun as exploring/learning with your own funcs, but help 
"?" can do some great things, including matching on datatype "? tuple!" 
is a quick way to lookup colours.

Thanks.  And is that colours or colors?  ;-)

; interesting question ... Rebol lets me spell it "colour" if I really 
want to :-)
alias 'color "colour"
view layout [label with [colour: red] "hello"]

Robert;  Make sure you check out  http://www.rebol.it/romano/and 
in particular http://www.rebol.it/romano/#sect1.1.anamonitor 3.0 
and 2.0.  Not something for your average I'm new resident but I have 
a feeling you'll appreciate Romano's utilities.

Here is one of my first encounters with unset!  when working on a 
tutorial to introduce console Rebol to someone who knows Common Lisp
>> m: [1 2 3]
== [1 2 3]
>> m
== [1 2 3]
>> probe m
[1 2 3]
== [1 2 3]
>> print mold m
[1 2 3]
>> mold m
== "[1 2 3]"
>> type? print mold m
[1 2 3]
== unset!
>> type? mold m
== string!
>> type? probe m
[1 2 3]
== block!
>>

the answer is interesting for  me as a newbie and lies in
>> source probe

; the error from trying
>>  n: print mold m
; natually leads to
help print
; and since this fails
p: write %tmp.txt :anything"
; with
help write

; we get to clarify binding words to values, functions, procedures 
 evaluation and returned values

; I hope to get tutorials prepared for OCaml and Scheme as well as 
Haskell and Curl, Perl, Python, Ruby and Smalltalk based on my experience 
as a newbie while I am still a newbie ...

; i.e.,
>> type? write %tmp.txt "newbie"
== unset!
>> unset? write %tmp.txt "new"
== true

both English Rebol books call print and prin 'functions'

The Rebol docs dictionary lumps all the words together as 'functions'

The challenge I have in introducing Rebol in a tutorial is to explain 
why the second expression fails:
>> c: open %temp.txt
>> d: close %temp.txt
; when explaining that the last line seen in
>> source send

; is not an indication that the function named send returns a value. 
 In many languages procedures can be called functions. Is Rebol one 
of them?

; not all mathematicians can add and many cannot teach mathematics 
but can teach naval history. and such.

>> c: open %temp.txt
>> e: insert c "test"
>> close %temp.txt

>> type? e         ; this is easy to explain to Smalltalker as in 
ST you cannot assume that a method returns self

they are all functions, as the all return a value. some return the 
value "unset!" which is treated somewhat specially by the interpreter. 
you cannot set a word to this value unless you use set/any, and you 
cannot get a word that refers to this value unless you use get/any.

unset! is mainly used to catch typos (eg. if you write pint instead 
of print you get an error), and it's used as a return value by functions 
that don't have anything useful to return.

I wil be sure to cover  get/any  and  set/any 
thanks

; using a context there is no problem traversing a path into nested 
blocks. But there is using nexted blocks alone.  Here is my first 
answer to this...
>> t1: [a "one" b "two" c "three"]
== [a "one" b "two" c "three"]
>> t2: [f t1]
== [f t1]
>> t1/b
== "two"
>> t2/f
== t1
>> t2/f/b
** Script Error: Cannot use path on word! value
** Where: halt-view
** Near: t2/f/b
>> pword: func [path 'word /local blk] [
[    return to-path reduce[path :word]]
>> do pword t2/f c
== "three"

; pword is my first pass at a function to traverse nested blocks 
which are not in an object; the alternative appears to be
blk:  get t2/f
aPathDeeper: make path! [ blk c ]
; anyone know anoth path to take?

; the local was a hold-over from an earlier pass at doing this


pword: func [ { navigate one deeper into nested blocks using a path} 
path 'word { must be a valid path refinement} ] [
  return to-path reduce[path :word]]

; simple nested blocks were not the issue
>> t1: [a "one" b "two" c "three" x [f "for"]]
== [a "one" b "two" c "three" x [f "for"]]
>> t1/x
== [f "for"]
>> t1/x/f
== "for"

; I only have the issue if I build t2 to hold some functor and a 
word bound to a block rather than the block, i.e., not
>> t1: [a "one" b "two" c "three" x [f "for"]]
== [a "one" b "two" c "three" x [f "for"]]
>> t2: reduce['functor t1]
== [functor [a "one" b "two" c "three" x [f "for"]]]
>> t2/functor/c
== "three"

t2/functor/x/f  ; also OK of course

; this issue persists 
>> t2: [functor t1]
== [functor t1]
>> p3: to-path reduce[ t2/functor 'x]
== t1/x
>> do p3
== [f "for"]
>> p3: to-path reduce[ t2/functor 'x/f]
== t1/x/f
>> do p3
** Script Error: Invalid path value: x/f
** Where: halt-view
** Near: t1/x/f
; there seems to be no way to "append'" to a path ??

>> p4: to-lit-path [t1 x/f]
== 't1/x/f
>> do p4
** Script Error: Invalid path value: x/f
** Where: halt-view
** Near: t1/x/f
>> t1/x/f
== "for"

; this works
>> p4: to-lit-path 't1/x/f
== 't1/x/f
>> do p4
== "for"

; but it is no help if t am trying to pass in the path the I wish 
to "extend" deeper

>> p4: to-path "t1/x/f"
== t1/x/f
>> do p4
** Script Error: Invalid path value: t1/x/f
** Where: halt-view
** Near: t1/x/f
>> type? p4
== path!
>> get first p4

** Script Error: get expected word argument of type: any-word object 
none
** Where: halt-view
** Near: get first p4

; using get first or get second or get last usually is handy diagnosing 
what is reported as a path but in fact fails as a path

>> p4: to-path 't1/x/f
== t1/x/f
>> get first p4
== [a "one" b "two" c "three" x [f "for"]]

; If I'm understanding this correctly, you are trying to resolve 
a single path to a value in nested blocks (I'll take the liberty 
of reimaging the example):

path: 'language/en/one
language: [en english]
english: [one "one" two "two"]

resolve path ; == "one"

; I'd look at this in two ways -- a) set up the blocks so the path 
works with 'do:

language: reduce ['en english]
resolve: :do

resolve path ; == "one"

; or b) step through the path and resolve each value in turn:

resolve: func [:path [path!] /local wd val][
    wd: first path: copy path remove path val: get wd
    while [all [block? val not tail? path]]
        wd: first path remove path
        val: val/:wd
        if word? val [val: get val]
    ]
    val
]

I am trying to compare what I can do in Rebol to what I can do in 
another language with functors

What hamstrings me is that a path cannot be extended unless the blocks 
are literally nested or in an object

I am hoping some one will da ythat in R3 path! is more like a series!
path: this/thing
path: append path 'what
rez: path

(sorry, missed an opening bracket in 'while)

path: 'this/thing
append path 'what
probe path
probe to-block path

sorry what is a bad choice
make that 'whatever

bind to two valid paths
compose with one word nested in a block
you can append all you want
type? is path
and the path will not be valid

my little pword func was the shortest thing I could build

path: join 'language/en 'one
probe resolve path
path: join 'language/en 'two
probe resolve path

The path is not valid, so long as you are trying to resolve it with 
'do.

why should that be so?

the path is just word1/word2 and then is just word1/word/word3

Only word1 ever binds to a value

word1/word2/word3 ; guy can't even type ...

The path! that my 'pword func returns responds as expected to 'do

Iin your example (again, if I understand correctly), 'do (or default 
behaviour) resolves each stage in the path.  So, with a given path 
-- t2/f/b -- it'll go t2/f == 't1-- but this is just a word, not 
the value associated with the word.

It's equivalent to this:
val: 't1
val/b

But is any valid deep path only the forst word has to have  a value 
associated with it.
  e.g. 
     block/tag1/tag2/tag3

Only if you're evaluating with 'do.

Even if I am doing
   result: constructedPath

That's sort of the same as evaluating with 'do.

What should the behavior of 'join and 'append' and 'insert be when 
passed a path and a word?

What I'm getting at is there are limitations in the default handling 
of paths.  But paths are series and you can evaluate them however 
you want to.

Yes, get first path is a godsend