World: r3wp

Jaime; Just so ya know.  Keep up the counter-arguments.  This is 
an issue that needs to be thought through upside down and backwards. 
 So far it's mostly been all pro few cons, and I probably have blinders 
on regarding the bigger pictures.  I have two very specific items 
in mind.

Well that and the coolness of being able to  load %random.txt

I hear you the "Script way".

But there is going to be a price for this one liner. Either in load 
time, security, size, and others.

I'm more of the PARSE/LOAD camp.

Agreed.  About there being a price, wherever it hides.

If I get my wish and you can parse ports in R3, that would deal with 
the major advantage that LOAD has over PARSE, that you can LOAD files 
and urls directly. PARSE on ports with a LOAD directive would be 
the best of both worlds. I only wonder how backtracking will be handled 
on direct ports.


I hope that you will be able to LOAD ports too, particularly LOAD/NEXT.

yes to all of the above, wrt backtracking, its not impossible, but 
its a hell of a complex algorythm.

Jaime, Maxim - please put your concerns into blog, so we can hear 
Carl's opinion on the topic ...

pekr, did you look at the blog?  I filled it up with (too) many comments, 
brian had a very good insight in modifying one concept I proposed.

Maxim; Never too many comments.

Carl talked once about removing the Xaw (Athena) from View linux... 
is there any information about this for R3?

another one which i think wont be in but i can ask ofcourse...will 
R3 have "transparent" Root-wnidow Layouts under linux?

both questions depend on the community - all of that is open source.

Owww...

REBOL/Command for Linux includes AGG (without View/VID), so no dependencies 
on any X11 libs, can be a workaround while waiting for R3.

I realy thought AGG was already inside rebol/view for linux ?

Oke ... now understand... That request I posted a few years ago... 
So that works in Rebol/Command... nice to know ...

could anyone explain tome, what is the port actor, as mentioned in 
Carl's presentation? What is difference between actor and awake?

actor is equivalent to current handler

eg in R2:

>> p: make port! http://www.rebol.com
>> type? p/handler
== object!
>> type? p/awake
== none!

another one - why do I need to explicitly state "do task"? Why there 
is extra set of brackets in make task! [[]] example?

in R3 it's called actor instead of handler, and the reason is that 
it is internally very different from r2 handlers.

ok, thanks for the actors explanation :-)

make has been changed so that it does no more take variable number 
of args

so if you want to provide a spec for the task you use a block inside 
the arg block

re tasks - it does not look natural to me ... you don't start your 
rebol script by stating [REBOL [] code-here]

you don't?

no :-)

all my scripts start with a rebol header.... do won't execute them 
otherwise :)

I can 'do %script.r, which does not contain whole script enclosed 
in special brackets ... well, it loads it into block, so actually, 
yes, but :-)

it is imo confusing - not compatible with how we specify scripts 
... but maybe I confuse it with modules. Simply put, typical rebol 
code is REBOL [header] body, not REBOL [ header] [body]

task definition looks exactly like the latter ....

afair you can:


 t: make task! [some code here] ; no spec, not sure it's supported 
 but i think so

or:

  t: make task! [[header] some code here]

without the word REBOL , that is :-)

ah, ok then ....

or maybe carl made it like make function!

make function! [[spec] [body]]

(i'm going from memory... i think modules were described as i said 
above so tasks should be similar, but function-like makes sense too 
if the header is mandatory)

anyway these are the kind of things that are going to change during 
the alpha phase in june

ie. we let some developers play with it just so that we can make 
final decisions on this stuff.

hmm, at least 4 of my msgs lost ....

seems ok now ... well, I just said that the syntax looks ugly - too 
many brackets :-)

but what is definitely issue to me is that it is not imo consistent 
with how we construct scripts ...

well it's basically going from make task! spec body to make task! 
reduce [spec body]

and task for me is kind of higher level construct as script or modules 
are ... well, kind of "instance" of "environment"

so you just write a wrapper task: func [header body] [make task! 
reduce [header body]]

if you look at it this way... i'd actually want it to not support 
the above example at all.

ok, so then take my note for the discussions .... pekr did not like 
task syntax :-)