World: r3wp

net-utils/net-log join "Type: " type: any [
	    all [new-dir? 'new-dir] 
	    all [new? 'new] 
	    all [dir-read? port 'dir] 

     all [port/state/flags and system/standard/port-flags/open-append 
     <> 0 'app] 
	    'file
	] 
	do select [
	    file [

  confirm-cmd port either port/algorithm = 'nlst [nlst-check] [list-check] 
		accept-connect port type 
		parse-dir-list port 
		if tmp: select locals/dir-cache to-file port/target [
		    port/status: first tmp 
		    port/date: third tmp 

      if any [none? port/size: second tmp 1024 > port/size] [port/size: 
      0]
		] 
		data-connect port 
		confirm-cmd port binary-type-check 
		if 0 < cmd-port/state/index: port/state/index [
		    confirm-cmd port restart-check
		] 
		confirm-cmd port read-check
	    ] 
	    new [confirm-cmd port write-check] 
	    new-dir [confirm-cmd port mkdir-check] 

     dir [confirm-cmd port either port/algorithm = 'nlst [nlst-check] 
     [list-check]] 
	    app [confirm-cmd port append-check]
	] type 
	accept-connect port type 
	if type = 'dir [
	    port/size: port/state/tail: parse-dir-list port
	]
    ] 
    port
]
close: func [port /local cmd-port cache-size][
    cmd-port: port/locals/cmd-port 
    if not dir-read? port [error-try? [confirm-transfer port]] 

    net-utils/net-log reform ["Caching cmd-port" cmd-port/host cmd-port/local-port 
    cmd-port/remote-port] 
    cmd-port/host: cmd-port/locals/tuple

See the first SELECT ? Now find the variable which is its VALUE argument.... 
 :-)

Maxim, now's the time to fix some things, no ?

I agree with the select (I was just joking, cause you know how serious 
this will have an effect on code :-)

But this raises again, the issue of trying to get backwards compatibility 
and is it even possible?  with so much changes in the air?

I sacrifice backwards compatibility, we have got incompatibilities 
already in the past and so what? Especially to View changes ....

and the user base is small. CNN and Wall Street won't notice

but changes like Anton's SELECT request invalidate MOST of REBOL 
code in one sweeping ARC.

but as for select ... uhm, not sure :-) it is about logical order 
of arguments, no? first, select, pick, find, all require "where" 
argument first, then "what" argument ...

do we have reversed order?

I keep swapping them too, from SQL with SELECT <columns> FROM <source>

we must question if such a change is better if it means newbies cannot 
use any public rebol code on rebol.org, for example.

same with FIND. it's not natural to say "Find in the kitchen a pot" 
in English

its consistency.  and although its not english, its damn easier to 
remember that way.  they all use the same "SERIES first" approach.

yes, I objected agains it during rebol 1.0 alpha, but Carl already 
chose such argument order for some reason ... I think that to change 
it nowadays would be an overkill

I totally agree with Maxim - we either change all, or none of them 
- it will be confusing .... and it would really break all the code 
...

probably because having series first means all arguments treating 
data follow it.

instead of having the series jump around in one function to another.

THAT would be damn hard to debug.

don't forget that it's not just style - some of them are actions, 
and actions only dispatch on the first argument.

Isnt 'switch exactly that, a reversed "do select"? i use 'select 
on variables, not blocks. then it is
> select data face/text

About english, "Find in the kitchen a pot" is ugly, but "look in 
the kitchen for a pot"?

It's poetic :-)

volker, that was the point I was making with FIND

That was why i was citing it :)

but i would argue more about the word "find" than the order of arguments. 
But maybe i am to used to "target first"?

(or is "look in" as ugly? Not native speaker..)

look in

 seems to be correct enough. I'm just used to finding the pot in the 
 kitchen, not finding in the kitchen a pot, thus I usually swap the 
 function arguments by mistake.

Technically it could work, if 'in would put its argument in front 
of the last call

> find pot in kitchen ; Kitchen would be passed as first argument 
now.
would be the same as 
> find kitchen pot
(sadly 'in is not available, and maybe its to biga hack?)

find pot @ kitchen ;?

Grabriele, Maybe  that is that actions only dispatch on the first 
argument. Has there been any talk of multimethods.  So far the only 
way to have native polymorphism is thrue ports. I wish rebol implemented 
multi-methods.

for those who want RSS feed for Rebol3 blogs, Carl has updated it.

http://www.rebol.net/r3blogs/rebol3-rss.xml

Jaime, could you please voice your multimethod request to blog comments 
section? I think that Carl is not checking Altme here anymore .....

Pity we can't take the comments and inject them into here.

the fragmentation of information is just increasing.

anyone know why the priorities of +, - and *, / are swapped. This 
is a little annoying, I think.

henrik, there are no priorities.

oh well, but it still forces you to rethink your expressions

jaime, i don't think multimethods have been discussed for r3. they 
would be nice... but really only if we get custom datatypes too.

a tend to agree with you, but some people say that priorities force 
them to rethink their expressions...

so, in the end, no rule is easier to remember than some rules, thus 
i got to like the rebol way.

you should be able to find my old eval function to eval (and compile) 
math expressions with priorities and so on.

(was posted to ml many years ago, some archive should have it)

It's explain in the doc : priority go from left to right, nothing 
more. The rule is different than the mathematical one we used to 
use. But it's also a "simple" rule, easy to remember.
So, 
>> 3 + 2 * 5
== 25

gabriele: luckily, Brett had a copy:

http://www.rebol.org/cgi-bin/cgiwrap/rebol/ml-display-message.r?m=rmlLNJK
Otherwise the trail could have ended here:

http://www.rebol.org/cgi-bin/cgiwrap/rebol/ml-display-message.r?m=rmlXSDC

It was easy to find Gabriele's eval script through the topic index 
at Rebol.org. It's at http://www.rebol.org/cgi-bin/cgiwrap/rebol/ml-display-message.r?m=rmlXWHS

interesting. wonder if it could be made into handling symbolic math...

Gabriele - as for multimethods, aren't we getting custom datatypes 
with rebol3? I thought Carl said that language will be "extensible", 
whatever extensible means though :-)

Priorities would mean more special cases for the evaluation - instead 
of a consistent op! behaviour.

It's not just + * - /, it's for // ** and or xor = > >= <= <> == 
=? too.

The left to right rule is itself quite an improvement in readability 
over the pure form:
>> * + 3 2 5
== 25

Please lets not make the mistake of using C precedence for basic 
ops. It will slow rebol.

and using parens work anyways.