World: r3wp

re Cyphre - I have trouble reaching him on ICQ, not to mention reaching 
him here. I am really curious, if Cyphre is going to be available 
for "another overhaul", but maybe I am too pessimistic in that regard 
:-(

Henrik - Carl mentions beta in few places ...  one of the being Twitter 
...

Pekr, yes I know. He has used nearly the exact same phrase "needed 
for beta" 1-2 years ago :-)

 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.