World: r3wp

Another application for matrices can be signal processing with native 
operators it could be possible to make things like jpeg compression, 
audio effects etc in plain rebol

And I think we have them already in Rebol ............ in AGG

Is it just me or does it seem Carl is trying to switch many things 
around in favor of newbies only?

:)

does it seem clear to me that the first thing rebol needs is more 
documentation?

We ALL are....

more in the sense of tutorials, guides and stuff... not references.

in a sense, I feel, some proposals from Carl stray away from rebol's 
current orthogonality ?

I mean anyone can re-implement first, second, third as pick 1, pick 
2, pick 3 if they want.   its dead easy.

No...you hit first....newbies....

No...nothing is easy, most people are stupid, and most peoplehere 
on Rebol3 are in teh 98+ percentile...  It just "feels" easy to you.

:)

can I propose something then?

Always....

I am driving so my responses are going to get really simple.

switches to maintain some of the compatibility with older scripts.

I find that many issues Carl is trying to solve ignore the fact that 
most people stop using rebol not because its syntax is different 
or because of return types... those are things we learn when we use 
any language...

most people stop when they actually try to do a concrete application 
within constrains and realise many things within the implementation 
of this or that... well, just falls short of working.

and the one reason we continue using rebol is because we are of the 
type of people who WILL download an RFC and fix the http, ftp, proxy, 
xml, (whatever) protocol ourselves.

rebol claims a lot of things... but falls short in general.   for 
my latest project, I had to re-implement http posting, and xml parsing 
myself and I'm still not finished.

don't get me wrong, I live and breath by rebol, but people who are 
interested, quickly get annoyed at little things missing under the 
hood.

rebol feels like a hybrid car.  Almost, but note quite enough to 
get new people out of their cosy stylish cars.   Its got a lot of 
promise, but at what cost.

I just though I'd share my stake on several years of trying (and 
finally succeeding) to use rebol commecially.

I agree...

I hate those - but ... me too!

I mean, I hoate those "me too" postings :-)

hate, of course

Feature request:  I propose SELECT's arguments should reversed, to 
be like SWITCH. I remember SWITCH being implemented and arguing to 
put the VALUE argument before the CASES block to make it easy to 
find.

are you on a mission to disable all scripts in the world  ;-)

So, for a SELECT, you won't have to search around with your eyes 
for the VALUE argument, as in this example from the FTP scheme which 
I am currently looking at:

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.