World: r3wp

but user types are still a mystery... there is no information leading 
use to beleive we will be able to complement the in-memory data with 
a molded form,  which can be loaded too.

I think datatypes is not enough as charaterization. You still want 
to encapsulate the methods related to a type.

R3 will have classes to... I just wonder why the artificial separation 
of prototypes, modules, datatypes and classes is needed in REBOL.

they can really all be one and the same, if the core system allows 
us to play with the internal accessors.   python does this beautifully. 
  you can make prototypes out of classes by implementing the accessors 
so they created a dict on each allocation, for example.

So this new lazy LOAD is kind of a PARSER of REBOL values + foreign. 
I think it maybe easier to provide  *rebol value rules*, so you can 
construct your PARSER as desired instead of triggering exceptions.

Just like default relust for alpha, digits, whitespace should be 
provided.

I look at this problem from two views.  wanting a forth style block 
editor and wanting to let a construction boss sit at home and edit 
his own data blocks.  The forth style CLI just needs strings...any 
string including something like  p [   putting an open bracket on 
a line by itself.  This can be done with string parsing and a dialect 
pass, but hey.  The other issue is a lot deeper.  I want the boss 
to type in $1,000,000 and not have to call me when load kakks and 
(when I'm not careful enough) breaking a script.

My reasoning is that the new feature is a mixed but I am afraid it 
doesn't really buy much.

which is what Brian and I are suggesting on the R3 blog.  brian's 
idea is to include LOAD within the parser as a directive.

I suggested supplying parse rules to load, but I feel his idea encompases 
mine but not the other way around.

mixed: "mix between scanner, parser, and interpreter".

read about it here, http://www.rebol.net/cgi-bin/r3blog.r?view=0078#comments

btiffin, You can always make a parser that stops at an invalid value.

And decide either to fail, or clean-and-continue.

Yeah, but that gets tedious, and being lazy, error prone when it 
is data dependant "bugs" that can break scripts.

Nah. That is easy to handle if you know how to construct your parsers 
properly. As easy an extra rule.

I wrap most things, properly (usually) but it's nice to let bosses 
be bosses without having to tell them that money has to be typed 
in with ticks instead of commas.

I understand. Only thing I am saying is that you can accomplish this 
without needing LOAD/lazy.

Yeah, but not in one-line of code  :)

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 :)