World: r3wp

do bind load %prg2.r self

but if you have nexting contexts, you're going to need multiple binds. 
also, while DO changes dir to the script's location, LOAD doesn't. 
so there is a difference. but, you can get into this kind of problems 
with #include too.

yes, that is another variant, although I prefer #include in this 
case (it changes dir, btw.)

(but only when doing preprocessing, i.e. some care needed anyway)

Gabriele, thanks! That "do bind load <something> self" is, what I'm 
after. :-)

That should be in the "Idiom Dictionary", Carl was talking about: 
http://www.rebol.net/article/0113.html
(When REBOL/Services or LNS is out.)

anyone got a definition for ++ ?  I thought I had seen one before 
but google failed me :(

; original simple functions
;;++: func ['a][do compose [(to-set-word a) (a) + 1]]
;;--: func ['a][do compose [(to-set-word a) (a) - 1]]
;;+=: func ['a 'b][do compose [(to-set-word a) (a) + (b)]]
;;-=: func ['a 'b][do compose [(to-set-word a) (a) - (b)]]

;++: func ['word][set word 1 + get word]
;--: func ['word][set word -1 + get word]

; handles paths 

++: func ['v [word! path!]][do reduce [either path? v [to-set-path 
v][to-set-word v] v '+ 1]]

--: func ['v [word! path!]][do reduce [either path? v [to-set-path 
v][to-set-word v] v '- 1]]

+=: func ['v [word! path!] value][do reduce [either path? v [to-set-path 
v][to-set-word v] v '+ value]]

-=: func ['v [word! path!] value][do reduce [either path? v [to-set-path 
v][to-set-word v] v '- value]]

Gee, you've got a few piled away there!

I don't actually use them. (maybe in one old program somewhere).

Just a small question: is it possible to delete directories from 
Rebol? 'delete seems not to work, or is it because the dir is not 
empty?

Try placing a "/" at the end of the dir:  make-dir %test  delete 
%test/

Oh, and yes, it needs to be empty.

There's also DELETE-DIR.

See Gregg, another secret solved. I didn't see that in the dictionary.

I _think_ that I had the slash, I'll be using delete-dir now. Funny 
thing I didn't know about it ... 
Thanks Gregg and James!

Its quite new ;)

Ahh, I see ... most of the time I try things like 

>> del <tab><tab> to see if there are other words like the one which 
_just_ does not do the job, but I forgot it this time. :-)

yup. And help "set" if it is somewhere in between. Note the {"},else 
it would show help for 'set in this case. (i guess you know that, 
just in case ;)

Better example would be: help "dir" ;)

what happened to Rebol's pattern matching in files?

I used to be able to do 

load %*.html 
well, that was valid in the year 2000.

I guess it was decided not to automatically assume the filesystem 
uses those wildchars ? Interesting. I honestly can't remember that.

I note that RT's documentation for the wild chars in SQL still makes 
a reference to REBOL's wild chars of * ...

Hi .... as me and my friend use RebDB, we currently have to simulate 
'join functionality. I gave the idea a little thought, and I remembered, 
there are Rebol natives as 'union and 'intersest. They even do work 
with /skip refinement ..... and we miss that 'join functionality. 
Would it be difficult to add such functionality to work with blocks 
for 'union, or have a new native? I have an example:

; structure - name, last name, address, zip code

table1: [ "Petr" "Krenzelok" "Navsi 645" "739 92"  "Johny" "Handsome" 
"Dreamland 777" "777 77"]

; structure - age, place of birth
table2: [ 33 "Trinec" 38 "Some town"]

join-block/skip table1 table2 4 2


Do you think it would be usefull functionality to have as a native? 
Would be fast and would give us db 'join functionality to some extent 
....

'intersect I meant :-)

Something older by Brett: http://www.codeconscious.com/rebol/rebol-scripts.html
http://www.codeconscious.com/rebol/scripts/array-tools.r

hi, do you find this behaviour natural?

spec: [
	a: 1
	block: [do [a]]
]

o1: make object! spec
o2: make object! spec
o2/a: 2
do o1/block
do o2/block

Thats actually surprising... IMHO it shouldn't happen.

It looks that I should post it to Rambo, then

Looks like a bug.

another presentation of the same effect:

objects: []
loop 2 [
	append objects make object! [a: 1 block: [a]]
]
objects/2/a: 2
do objects/1/block ; == 2 !

It looks like the context for the nested [a] in the spec gets set 
while creating an object.

the behaviour is caused by the fact, that MAKE doesn't copy the SPEC 
argument

; After pasting the first example, I can:
reduce last last spec
; == 2

Sorry, == [2]

The is the kind of side effects are quite dangerous, imo the current 
behaviour seems like a bug and breaks the least surprise premise.

Or doesn't deep copy.

strange isn't it?
same? o1/block o2/block
== true
But if you change the spec to
  block: copy [do [a]]

They are no longer the same, but still return the same value. Odd!

Chris was ahead of me there -- a working solution is
  block: copy/deep [do [a]]

You would need to copy/deep.

:o)

yes, that is true, I wrote a similar example to my Bindology article 
quite some time ago, where it was "clashing" with recursion. Here 
it is a problem even without recursion

Should programmers concern about copy/deep when creating new objects 
from a spec? It seems strange that they do.

As the interpreter is working now, they should, at least in case 
of recursive code or objects with variables having block values

The easiest rule is to write make object! copy/deep spec instead 
of make object! spec

But is this appropriate, why not just have copy/deep by default on 
make object! ?

the reason was, that it is slowing down the interpretation in cases 
it isn't necessary

(I would say, that it can be considered "premature optimization"?)