World: r3wp

When searching in a string type for any string type, the type is 
converted. Same for block types. And path! is a block type.

The only way to avoid the conversion is to use /only.

I was wrong earlier about the reason Henrik's find didn't work.

yes, my initial reply was a bit hasty too.

Don't know whether this has been discussed / RAMBOed yet, but I think 
a smarter reduce (either a refinement or another word) which could 
handle:

	reduce [now then]

instead of requiring:

	reduce [now 'then]

or

	compose [(now) then]


would make writing dialects a lot easier as unset! is rarely a legitimate 
value within a dialect (i.e. I'd like to reduce blocks before parsing 
and words without a value should just be left as is).

Something like:

reduce2: make function! [
	block [block!]	"Block to reduce"
	/deep		"Reduce nested blocks"
	/local blk

 "Evaluates a block of expressions, skipping words without a value, 
 and returns a block."
] [
	blk: copy []
	foreach word block [
		either block? word [
			either deep [
				insert/only tail blk reduce2/deep word
			] [insert/only tail blk word]
		] [insert tail blk either value? word [do word] [word]]
	]
	blk
]


>> reduce2 [red x now now/date (1 + 1) [red x now now/date (1 + 1)]]

== [255.0.0 x 24-May-2006/13:12:14+10:00 24-May-2006 2 [red x now 
now/date (1 + 1)]]

>> reduce2/deep [red x now now/date (1 + 1) [red x now now/date (1 
+ 1)]]

== [255.0.0 x 24-May-2006/13:12:26+10:00 24-May-2006 2 [255.0.0 x 
24-May-2006/13:12:26+10:00 24-May-2006 2]]


but as a native! and able to handle funcs with args (e.g. reduce2 
[print "hi"]).

Here's a different approach to get the result I'm after:

cast: make function! [
	block [block!] "Block to cast"
	words [block!] "Words to convert into literal words"
	/local blk word
	"Casts nominated words within a block into literal words."
] [
	blk: copy []
	repeat i length? block [

  insert/only tail blk either find words pick block i [to lit-word! 
  pick block i] [pick block i]
	]
	blk
]

>> cast [area red button green 'btn blue] [area button]
== ['area red 'button green 'btn blue]
>> reduce cast [area red button green 'btn blue] [area button]
== [area 255.0.0 button 0.255.0 btn 0.0.255]

>> reduce/only [area red button green 'btn blue] [area button]
== [area 255.0.0 button 0.255.0 'btn 0.0.255]

Does that do what you need?

Doh! I'm an idiot. I even read the help text on reduce ... but failed 
to read the text associated with the words refinement. Thanks for 
that, that is one refinement I'm *never* going to forget now. ;)

Please disregard my previous postings.

Yeah, I get that feeling here a lot too :)

REBOL keeps surprise us again and again! :-)

I was a little surprised that the lit-word didn't turn into a word. 
That could be useful. I'm going to do some experiments to see what 
else reduce/only doesn't do. Should be fun.

Why I am not able to OPEN file which I can READ ?

Example?

'read must 'open a file

Open/read may be the difference

Ladislav yes, that was the problem, thanks

Ashley, but reduce/only doesn't perform according to your  initial 
spec "Evaluates a block of expressions, skipping words without a 
value, and returns a block."
>> reduce/only [now then]
** Script Error: then has no value

Huh? that's not the error I get:
>> reduce/only [now then]

** Script Error: reduce expected words argument of type: block none
** Near: reduce/only [now then]

Ah but maybe that's still your point - not what Ashley asked for.

Docu is wrong. it does not reduce words in the /only block. But it 
also rejects functions. so
>> reduce/only[then][then]
== [then]
but it also rejects functions, here unfortunally:
>> reduce/only[now][]
** Script Error: Invalid argument: now
because of security-reasons (draw-blocks from untrusted code).

but reduce/only doesn't perform according to your  initial spec
 True, on two counts:

1) It doesn't evaluate expressions (even if parenthesized)

2) You have to predetermine what words to ignore (less of an issue 
for dialects)

I still can't see a simple way of doing the following:

>> reduce [b: button red form now/date]
** Script Error: button has no value
** Near: b: button red form now/date
>> reduce/only [b: button red form now/date] [button]
** Script Error: Invalid argument: form
** Near: form now/date
>> reduce/only [b: button red (form now/date)] [button]
== [b: button 255.0.0 (form now/date)]


although at least the last case gets most of the way there. What 
I'd really like is:

>> reduce/ignore [b: button red form now/date]
== [b: button 255.0.0 "25-May-2006"]

I am using my BUILD dialect http://www.fm.tul.cz/~ladislav/rebol/build.r
to do it as follows:

>> build [b: button ins red ins form now/date]
== [b: button 255.0.0 "25-May-2006"]

or, another alternative:


>> build/with [b: button red form now/date] [red: system/words/red 
form: get in system/words 'form]
== [b: button 255.0.0 "25-May-2006"]

Use do/next in the parse rule. (that's the reason I suggested the 
DO command for parse some time ago...)

Not sure I understand, a small example would help. ;)

Or was your comment intended for Ladislav?

Ashley: reduce /only -- Only evaluate words and paths, not functions
So the results you are getting above seems logicalto me.

I understand what reduce/only is doing, it's just not doing 100% 
of what I want! ;)

Ah got it ;-)

I think VID like parser is the way then.

Funny, that's what Anton just said in the RebGUI group. ;)

rest: [1 + 2 button 3 + 4] 
out: copy [] 
while [not tail? rest] [
    either find [button] first rest [
        append out first rest 
        rest: next rest
    ] [
        set [res rest] do/next rest 
        append/only out res
    ]
] 
?? out 
comment "or parse" 
rest: head rest 
out: copy [] 
parse rest [
    any [
        set word ['button] (append out :word) 
        | rest: skip (
            set [res rest] do/next rest 
            append/only out :res
        ) :rest
    ]
]

That trick should help with rebgui too.

Ashley, the idea is that in parse, when you get to something you 
want to evaluate, you set a marker and use do/next. like in volker's 
example. my compile-rules provided  a way to do this automatically 
:)

If you can convince Carl to take that feature please :)

the problem is that it "breaks" the parse logic, because you cannot 
backtrack a do/next (side effects)

Volker/Gabriele: thanks, got it now.

I would left that to the user.

It has its purposes without side-effects. And you can have side-effects 
in the parens too, eg a do/next ;)

Is there any script for ftp upload of large files?

srcp: open/direct/read src
trgp: open/direct/new/write trg
while [not none? buf: copy/part srcp 1000][
	prin "#"
	insert trgp buf
]
insert trgp crlf
close trgp
close srcp

Does that work for FTP ?

yes:-))) the insert trgp crlf is not needed

the trick is, thet there must be the /new switch in the ftp port 
(as at least my ftp server do not support append)

Hm, but now how to make directory thru FTP:(

ah it's easy as well, just using make-dir... I'm reboling so many 
years and still am so suprised how simple it can be:-)

Just be aware that make-dir/deep usually doesn't work with FTP

anton has a fix for that

I found that make-dir/deep doesn't work, so I patched FTP OPEN so 
that it creates deep paths as necessary.