World: r3wp

 We're nearing the time to move R3 into beta.

 sound more concrete imo - it is taken from latest Twitter message 
 :-)

If so, it could be, because he wants to remove the GUI from 3.0. 
I know he is going a bit back and forth on that.

remove GUI from 3.0? Interesting - never heard of it ...

It's just my speculation. The GUI can be removed if desired. It's 
going to be a module.

I doubt it ... do you think that module can have easily binary code? 
:-) You can remove VID, but what about View kernel? I doubt it. But 
we still have to see Core and Host isolation interface. Extensions 
are something different. We are still waiting for Host code release 
...

Henrik - a bit OT here, but maybe not. Have you looked into UIs of 
iPhone, HTC Sense (TouchFlo 3D)? I wonder if those glossy nice icons 
and other UI elements can be done using AGG and gradients, or are 
those things precisely rendered using 3D tools? Or are they just 
non-scallable bitmaps?

http://www.htc.com/www/product/touchdiamond/touchflo-3d.html
http://www.htc.com/www/press.aspx?id=103534&lang=1033

Well, to my mind, the GUI is written with Rebol code (it can be exported 
in a module). The graphic engine (GOBs, draw dialect) will stay in 
the core.
It depends of what you call the GUI.

Pekr, OSX traditionally uses 512x512 32 bit bitmaps for icons. I 
assume it's the same for the iPhone.

they are usually made with 3D tools and Photoshop and the like.

releasing a REBOL beta without GUI is a VERY good idea.

with extensions all of the View internals can be outside... its basically 
AGG with a set of predefined hooks.  The only detail would be custom 
datatype... which should eventually reach extensions... maybe Carl 
could just build a special (undocumented) extension hook so that 
cyphre has access to more stuff, without the hassle of supporting 
it as a feature for the public.

on my part, once Carl adds either one or both of my requirements 
for the next evolution of extensions, then I can proceed with a fully 
independent version of a GUI written in OpenGL... no need for any 
internal view stuff a part from the image! datatype... not even window 
manager.

not sure it is good idea at all. But product packaging strategy was 
never explained for R3. Will there be Core, Command, View, Base like 
products? I am not sure, that technologically, R3 is done in such 
a way, so that such separation is possible (= all View internals 
can be placed outside R3 as a module). Also - having it optional 
as a module can lead to split of efforts once again.

So, I am still curious, how Core and Host parts are being abstracted/separated. 
And even then such separation does not mean, that View can be easily 
extracted outside as a module. Extracting only VID is imo nonsense.

to me REBOL the language and REBOL the platform are two different 
things.   forcing view as a requisite to rebol does not allow the 
language to live on its own.


if RT release the equivalent of core and makes that stable, we can 
already build a lot of apps, Back-ends, services, clients, etc.  
I'd rather have networking protocols, a stable set of mezz, continued 
improvements on extensions, than a lot of time waisted on view, delaying 
yet again all we can do with core already.

the OpenGL GUI will not need view, and if someone wants to make a 
cocoa extension or a windows native gui extension... they should 
not be forced to include view in their binaries.

a platform like view is a good thing, not saying it isn't, but its 
a different thing... to me, R3 is about the maturing of the language 
and of its interpreter.

Then good luck to RT, as they should find another mechanism, of how 
to physically isolate various components. With View, there si event 
queue involved, so I wonder, how the eventual split so that you "import 
View can be done. While I like REBOL.dll idea and its isolation, 
I don't like one homogenic Host portion code. It will lead to tonnes 
of various releases. Any ideas here? Could extension isolation interface 
be used for Host code and its componentes? Or are there different 
requirements? I will probably post to R3 Chat, to provoke some ideas 
from Carl. So just stop me, if you think that what I am asking is 
eventually very obvious :-)

At least we need 2 releases: Core and View

not sure those are planned ...

ok, posted Chat questions and suggestion for blog article describing 
"REBOL packaging methods"

Just noticed something else interesting about PHP. I just tried to 
generate an exception by division by zero. No exception was thrown! 
Instead, the result of the above expression was a boolean, false.

Just mulling it over, and I think I like it.

(but only passing consideration, not sure about it.)

Hehe, trying to google something about catching errors, I found Elan, 
Andrew Martin discussing the topic with you, Anton :-) Almost forgot 
those guys we once had ....

http://www.mail-archive.com/[rebol-list-:-rebol-:-com]/msg02468.html

Re. new datatypes. Would all of set-paren!, get-paren! and lit-paren! 
make sense? Working like this:

>> a: 4
>> :(a)
== (4)		; type paren!
>> '(a)
== (a)		; type paren!
>> blk: [a b c]
>> (blk/2): 42
>> b
== 42

I suggested, a get-block! should work, so
:[a b c]
was the same as
reduce [a b c]
Maybe it's better, if it was:
reduce [:a :b :c]
?

I came to think of symmertry between parens and blocks. It make sense 
to me to have a lit-paren! datatype. What about a lit-block! datatype? 
The thing is, parens are evaluated by default, blocks are not. So 
a block acts like a lit-block! would, I guess. Is it a good idea, 
that blocks are not evaluated by default? A lot of functions take 
blocks as arguments. Some functions reduce their block argument, 
some don't. This can be confusing. If blocks were always evaluated, 
functions didn't have to reduce them. And then a lit-block! datatype 
would make sense.

Comments?

Example of functions, that treat they block argument differently:

>> first [a]
== a
>> print [a]
** Script Error: a has no value


If blocks were always evaluated, and we had lit-block!, it would 
look like this:

>> first [a]
** Script Error: a has no value
>> first '[a]
== a
>> print '[a]
a

Consequense is, functions had to be defined using lit-blocks... Nah, 
probably not a good idea. ;-)

*Consequence*

The tuple! datatypes is in the scalar! typeset. Isn't it more like 
a series? Maybe it's because, a tuple can be max 10 bytes!?

John; I've become quite a fan of REBOL unreduced block data.  Super 
handy and learning the wisdom of it is a right of passage.

tuple! is a scalar  imho, well a scalar "record"    insert 1.2.3.4.5 
6  would do what?

Maybe produce 6.1.2.3.4.5. Tuple has some series things to it:

>> second 12.34.56
== 34

Sorry John ... I had ^s turned off ... drop that last snarky bit 
about   insert.   Stupid question that could very well have some 
intelligent and reasonable responses.

:)

But I still see a tuple! as a scalar type with no head or tail really.

I hope, we can one day make new datatypes. I would make a complex 
datatype. Wouldn't it be cool to be able to calculate:

1.2+4.5i * 3.14+1i

Maybe it's too much to hope for, to be able to enhance the lexical 
analysis with new datatype recognision?

Or a range datatype:

>> blk: [a b c d e f g]
>> blk/3-5
== [c d e]

User-defined datatypes won't be recognized lexically, except perhaps 
in serialized form. However, serialized datatypes have to be REBOL 
syntax inside the block. It's too much to hope for REBOL to become 
Perl, or get Lisp's read macros.

You can use whatever syntax you like inside strings though.

Tuples are scalars because you can do math with them. They aren't 
in series! because they don't have position, same as bitset!.

John, actually previous version of rebol had "aggressive" evaluations 
on some blocks in some circumstances and it was quite annoying in 
fact.  it got removed in 2.3 IIRC forcing us to reduce a little more, 
but now we have control.

if the rebol parser catalogued junk, it could shift to custom datatype 
hooks (just like parse tries to match patterns) until it finds a 
rule that says... "YES... up to here, I know what this means".

it definitely is possible language-wise, we are already doing it 
with string parsing and using load/next.  The defining moment here 
is the decision by Carl to "let go" of  the total expressive control 
of the language, and that will not happen soon IIRC.  its already 
cool that he has decided to open source all but the deep core of 
the language.

maybe with R4, after all of the goodies this opening will have brought, 
he will be able to contemplate opening up a bit more.  There is always 
a risk that letting go of *total* control can warp your creation 
to something you don't like.  But my experience in a decade of REBOL 
shows that stuff which isn't "sanctified" by RT have a lot of difficulty 
picking-up speed.


When you (i.e. Carl) spend 10 years on a project and it doesn't take 
off in-part because the responsability of keeping control stymies 
its growth, to a slower pace than that of the industry, IMHO you 
realize that the possible upside to *total* control definitely is 
dwarfed by having a mass of like-minded peers who move along with 
you.  


obviously no one sings exactly the same tune, but you need to try 
out stuff in order to know if its really a good or a bad idea... 
I'd rather have 100 people doing this, and then selecting the obvious 
clear winners than trying to muse about it, try a single idea and 
finally realize it wasn't a good idea.


Plus, what is good philosophy for RT isn't good for everyone... the 
proof is that the PITS model isn't enough for everyone.  Even RT 
had to acknoledge this.

REBOL "The language" is IMHO the best on the surface of Earth, but 
the platform (the actual executable, the desktop, view, IOS, et all) 
all show signs of tearing at the seams when you really want to "DO 
REAL WORK". 


You can get by, but its often painfull, or result to dubious work-arounds. 
  I have a lot of experience in big REBOL apps, so its not just word 
of mouth... I'm one of the few who has been succesffull at PITL work 
in R2 (hobby and commercial) for years.  But not everyone likes to 
say that problem-solving the platform itself is part of the work. 
 Most people want to work, they don't have time to try and fix view, 
or some tcp scheme, or charging their clients 30 hours to find a 
way to make 'CALL  work properly (or implement a MS COMLIB hack).

this looks like a vent, but its not.  I'm actually happy about everything 
that is happening with R3.   :-)