World: r3wp

Nope, this displays two lines:

header
 and "out" as in all my former tries ;-)

Literally that is I mean.

Yeah, REBOL treats block data as - don't reduce this - by default. 
 Try Gregg's sample.

Same for btiffin and Gregg; it outputs out as a literal string in 
the output row

In R2 you could specify data: out; maybe there is an option doing 
the same trick?

Try this;    a: 1 b: 2 c: 3    d: [a b c]

Did you use the exact code I posted? It works here.

You can copy it from here and use "do read clipboard://" to run it.

Sorry Gregg, I missed the point of the compose! Stupid ... Retrying 
now

Yessss Gregg, it works. But it isn't the most elegant solution. Neat 
trick though :-)

That's why I said I don't consider it a real solution. I don't think 
we have face accessors in place yet.

Maybe Gabriele can shed some light on the inner workings of this.

OK, I'll be patient then. Thanks anyway!

Arie;  This is a REBOL paradigm.  Block data is literal.  Your [out] 
 block is just that, a block with the literal word 'out  in it.  
It needs to be evaluated (reduced) to get at the value of out when 
inside block markers.

btiffin: yes, but I don't know a way yet to achieve this within the 
r3 text-list specs as known today, hence the trich Gregg showed which 
is a kind of meta-reduce :-)

trich is trick

Ok.

note that text-list will be replaced in upcoming VID prototypes. 
it's a stopgap solution.

Henrik: ah, thanks; that is useful info!

(it's just too damn ugly :-))

Are some parts of R3 already considered "final" (minus bugs, the 
need to reconsider, ...) just like "for the moment we believe there 
won't be any major changes"? 
And if yes, are these documented somewhere?

I am not sure. Some kernel parts for sure. Just recently we await 
release of Unicodised R3, which internally changed many things. Then 
Unicode will be kind of final :-) Modules and plug-ins should follow.

Dunno, maybe networking kernel is final, we just need more schemes. 
Currently we have only http scheme.

I was specifically thinking about network part, and wether it would 
be worth digging in deeper.

I would guess that until unicode & modules & tasks are given some 
soak time, many many things are up for change.  Nothing in the area 
of mezzanines would be stamped final yet (imho) as Mr. Hawley hasn't 
optimized away  each and every (while few) stray bit yet  :)  (plus 
DevBase has yet to roll large).   Umm, in details ... I'm pretty 
sure Carl has nailed down most (or all) of the conceptual layers 
and the interfaces won't change as much as internals might.

Ingo;  I would say dig in.  If only to blaze trail for the rest of 
us.  :)

Hmm, but maybe networking will not be affected that much. It is already 
device based propably, running upon async core. I think that studying 
it, including http 1.1 Scheme from Gabrile Santilli laboratories, 
is worthy experience anyway :-)

While we're at it ... I just tried 

>> echo %http-scheme.r 
>> probe System/schemes/http

and got a "Rebol system Error #1405: I/O error"
 Program aborted abnormally ....

... I forgot ... this is on linux through wine, so maybe it's not 
really rebols fault. I'm not sure about the current when and wheres 
of error reporting for us "outsiders" ;-)

Confirmed with 2.99.4.3.1 4-Jan-2008/17:22 build native Win98

Umm, confirmed crash

Is it possible to get the source somewhere else?

write %http.r mold system/schemes/http

Thanks sqlab, I was actually stuck in my own thoughts here ...

Question on alternate UI options, specifically ChUI (terminal style) 
or mobile options would be of interest to me.  Is anything planned 
or expected that would apply to those areas of UI implementation?

it's not planned right now, unless someone steps in and does it, 
but it requires VID3 to be about done, before that can happen. The 
focus is currently on a scalable DRAW based user interface.

but it would be fun to do a low-color, low-res VID3 GUI. :-)

Thanks Henrik, some comment recently made me wonder if I had missed 
something on that front.  I like scalable DRAW based as an option 
too. *smile*

IMHO, this is the right way to go:
http://en.wikipedia.org/wiki/Dynamic_Language_Runtime
My hope is that REBOL3 will be implemented over this framework.

So do I, though not as the main implementation.

Why this one? Aren't there also other VMs, which could be interesting? 
LLVM, Parrot?

Ah, .Net related ... so integration ... well, we might need to support 
that one, of course if it allows us to interface .Net, other than 
that there is no sense .

prot-http.r should be in devbase. also... we'll eventually publish 
the docs.

That's why I like it, Pekr. It seems to me to be the best way to 
integrate .NET with REBOL using fully managed code.

Aside from that though, not much point. Even if you are talking about 
the Silverlight or Compact runtimes, it's still much larger than 
REBOL on its own engine. As for speed, who knows; a lot of smart 
people are working on the DLR.

As for REBOL3 on .net ported on the DLR I think of having available 
all the libraries, classes, and object of the framework and from 
other languages.

This will bring much attention to REBOL, a wider odience, a vast 
amount of material avaiable, the opportunity to write bigger applications. 
It is a whole new word that opens. Also, REBOLERs using of the Microsoft 
platform will migrate to the "pure" REBOL when needed.
I  consider this step a winning move from every side of the view.

Also, as other languages are ported to JAVA a porting of REBOL on 
it would open a lot of opportunities from this other side too. Look 
at this article for an overview of JRuby: http://www.javaworld.com/javaworld/jw-07-2006/jw-0717-ruby.html

Things such as JRuby and IronPython are independent implementations, 
so you are free to reimplement REBOL in Java and .Net...

Kaj, having the idea does not mean I am able to implement it !