AltME groups: search

But in short - Red is going to be compiled language, and it will 
probably get some kind of JIT too, to allow interactive stuff like 
console. Red language compiles down to Red/System, which is kind 
of VM for it. In fact, it is REBOL-like low level wrapper to C, allowing 
some bindings. Red/System apps recently run even on ARM, eg I am 
able to run it on my HTC Sensation. But that's raw ARM Linux, no 
Android API linking yet ....

Hi Doc, I didn't express correctly in my last post and you missed 
the point - I already know that Red will be prototype-based but the 
question is : will the object model implementation you'll use be 
flexible enough to permit you and/or the end-user  to easily extend 
  Red with other  new types, or change primitive functionality and 
semantics at some later time. The author of this article has done 
some studies and experiments about this fact and within his 16 pages, 
he explains how it could circumvent these possible limitations without 
sacrificing efficiency - even if I'm not advanced enough to take 
his word as truth per se. I thought it would be useful to you to 
see such writing before you committed to much material, based on 
your current architecture and internal implementation details - about 
which I don't know anything, I must confess. Sorry if this is more 
of an annoyance than a useful tip but I thought it could be useful 
as a reading to anyone interested in implementing some programming 
language - be it not fully Red related.

In fact, if we could merge struct, unions and bitfield in a single 
concept, with a nice syntax, that would be the best option.

For CGI, you should obviously pre-compile them if you want performances. 
The future JIT-compiler should be able to handle such cases fine 
though.


But yes, the goal is to be able to run Red scripts directly in the 
same way REBOL does. The fact that Red compiles them should be transparent 
to users. The -o option will be roughly equivalent to what encap 
provides (except that scripts will be compiled to native code).

Doc - maybe what does Arnold mean is just simple addition of Downloads 
section, and providing just few links for particular branches - https://github.com/dockimbel/Red/zipball/master
... but - we can live without it if other things are more important. 
But - there might be some truth to the fact, that not everybody is 
skilled to fight with Github "complexity". It was an obstacle for 
me too, although I found my way thru ... but only because of your 
help :-)

I can think of using to-head and to-tail. My opinion is you should 
have a more descriptive name for your variable. So length-of-cityname 
instead of length. The length could be of anything and the variable 
could be reused. Besides native English speaking programmers have 
always faced the fact that their prime candidate for variable names 
were taken because they were a reserved word. Imho so is should stay 
length? and not be length-of though that last one saves me from pressing 
a shift-key.

The compiler is using two ways to encode the fact that a function 
is used as a callback:

- through the CDECL attribute presence (destined to be called by 
external code)

- through the internal CALLBACK flag that is assigned to all functions 
that get their pointer passed as argument (get-word! syntax).

In fact, once done, it would be the first nano-kernel written in 
Red/System. ;-)

Though, Ladislav claims he and Carl did encounter such issue at least 
once

 - I am claiming that I have revealed a bug in Carl's code caused 
 by the fact that indices are not isomorphic to integers, i.e. they 
 "contain a gap". That is a totally different issue than whether indexing 
 should be 1-based or 0-based.

That is caused by the fact that there is no gap in the series, the 
gap is only caused by "unreasonable thinking".

I'm inclined to continue on the one-based convention that worked 
pretty well in R2 for many years
 - actually, R2 is "hybrid", since SKIP is zero-based, in fact.

Yes, I can in this case: "unreasonable thinking" here is the fact 
that the "mathematical model" - in this case the numbering of positions 
in series differs substantially from the properties of the object 
it is modelling - in this case there is a difference between the 
"no-gap in the series" versus "gap in the mathematical model".

SKIP works with offsets only, it's not related to indexing.

 - that is not true, in fact. It *is* related to indexing, since we 
 may always use PICK SKIP SERIES N M versus PICK SERIES K and these 
 things are realted, like ir or not.

Numbering positions in a series is, in other words, characterized 
as "mathematically modelling 'positions' in a series". Your "inbetween 
positions" are something that does not exist in the series in fact.

Tail position is inbetween, underlying implementation details cannot 
change that fact.

Tail position is inbetween - actually not. You can write: INSERT 
TAIL SERIES #"a". You do not insert the character "inbetween", in 
fact.

If you realize that indices are one degree vectors.   A lot of this 
discussion becomes moot.   vectors of length 0 are considered impossible 
when considering only natural numbers (due to 0 divide).  This is 
why I consider R2's handling of indices proper.   


As such, any series "position" is not AT a value it is LOOKING AT 
a value (oriented in positive direction, starting at a point in space 
which is "0").   like extending your arm to grasp the nth thing in 
front of you.  


Tail are 0 length vectors (thus mathematically imposible), when we 
are beyond  the last item edge we are at the edge of space.   you 
cannot "take" the tail item, there is nothin in front of you, just 
as you cannot "take" the 0th item, there is no such thing, 0 is the 
origin of the vector).


when we consider series indices to be vectors, we see the natural 
relationship which Ladislav pointed with SKIP and other methods.


with vectors, things like COPY/PART make sense in the negative direction, 
just as well as in the positive direction.



In R3, this was changed to indices being OVER a value , with the 
first item requiring you to look down and then away for other values. 
 The issue is that index 0 is looking backwards... that doesn' map 
to any good reasoning.  In fact it creates many weird inconsitencies 
in the model, when you try to describe it.


R3's series changes seem like a kludge work-around to map non-vectorial 
infinite integer space to a bounded vectorial space. sacrificing 
model integrity in the process (while trying to ease its mathematical 
properties).  R3's series *may* be "easier to count in a loop"  but 
the values being used make no sense.   counting backwards requires 
us to manipulate the indice for it to "make sense", whereas before, 
counting backwards was the same as counting forward.  we where just 
LOOKING in the opposite direction (the vector's orientation is inversed).

My note to Max's contribution:


- in REBOL, blocks of length 0 are not "impossible", that is, we 
have to use a nomenclature compatible with this fact

The issue is that index 0 is looking backwards... that doesn' map 
to any good reasoning.  In fact it creates many weird inconsitencies 
in the model, when you try to describe it.

 - it may not be a "weird inconsistency", but it is almost imposible 
 to describe to a newbie in a reasonable way

Ladislav, I fully agree. I don't think that "0 points backwards" 
is particularly elegant either, but I'm willing to explain it ("0 
points to the element before 1") and find it much better than having 
to explain when and why you have to very careful with computing indices, 
or even debug (R2) code that was written unaware of this fact.

Andreas: what do you propose to replace "foo/-1" if negative indexes 
are disallowed? "first skip foo -1"? - In 1-based indexing without 
negative values it should be PICK-BACK FOO 2, in fact, which is awful

I must have missed the proposal of BASIS?, but the fact that it would 
be a function or variable implies that it would be used to detect 
a global setting, like system/options/binary-base. Global settings 
like that have proven to be a universally bad idea in practice. Local 
settings are better.

Still the fact that `pick series 1` gives you the first item from 
current series position, makes the 0 position awkward.

Please move the discussion whether "0 exists" elsewhere. REBOL's 
integer! corresponds to integers and includes 0. Unless you want 
to change that as well, that's a fact we have to live with.

It's just a dialect for going in the opposite direction

 - it is not, in fact. (PICK SERIES INDEX) is just an evaluation of 
 a function, not a "dialect"

It's just a dialect for going in the opposite direction" - it is 
not, in fact. (PICK SERIES INDEX) is just an evaluation of a function, 
not a "dialect""

(what is interesting is the fact that when you rely on this, you 
get "kicked in the butt" like Carl was)

(what is interesting is the fact that when you rely on this, you 
get 
kicked in the butt" like Carl was)"


I respectfully disagree. :-) You are right in that my proposition 
doesn't exactly match the requirements, because the requirements 
imply a 0-based reference that I've missed. So, here's a corrected 
version that matches your requirements:


    head-index?: func [s [series!] i [integer!]][(index? skip s i) - 
    1]


I am probably too influenced by the way Carl designed R2, but I still 
think that a 1-based index system has value. (Let's save the 0-based 
vs 1-based debate for another day)

just a note: there is absolutely no need to support the end! datatype. 
REBOL doesn't support it either, in fact.

No, we've been publishing that fact for almost two years now. I don't 
know what else we can do

The fact that you're complaining means that the optimisations are 
missing, isn't it?

In fact, what I think is, that Saphirion was really close to the 
GUI engine, which adressed most of what we wanted to solve by VID2 
to VID3 transition. It was just not polished. And because of that, 
ppl did not find it attractive enough to play with. And that's a 
real pity. Anyone doing native platform GUI will make me to close 
that demo at first sight, easy as that. Doc is in kind of difficult 
situation - as we can see, many former/recent rebollers are still 
interested in View like engine. The same reason why Doc dismissed 
LLVM in Carl's blog post, the same reason many will dismiss attempts 
to link to GTK, Enlightenment, etc - I don't want to use 5+MB crap 
...

Not that it matters to you, but my code uses FUNCTION which comes 
from R1, in fact

I like things that are different to look different. But we don't 
have many goods chars left as leading or bracketing sigils, and I 
don't know if Doc has anything planned for those (e.g. [! @ & ~ | 
_]). 


The doubling of a sigil, to me, seems more like something we want 
to use as a convention, not a datatype. But the real question is 
what value each datatype adds. I've asked Carl a few times about 
a marker! type, for use in tagging locations in documents. Good chars 
for those are not easy to type († ‡ §), but could have mappings from 
(+ ++ $ $$). And now hashtags are a widely used meme. What lets us 
add meaning and clarity to the things we write, beyond just code. 
I still think REBOL's great success in expression comes from the 
fact that it was designed for data exchange.

Thanks Doc for sharing this information and Kaj for doing this GUI 
binding, paving the way for newcomers and sharing the source for 
deep study. When I will be going back to my former status (more free 
time) I plan to deeply study Red/System in parallel with the C language 
just to be able to write some small doc (or book) to help newcomers 
to start with Red/System after coming from the C environment. In 
fact it's a long time I planned to do it for myself first but never 
found the time to do so when I worked as a teacher in the past. Now 
I hope I will better drive my diary to cope with this new planniing 
!!!

Well, in fact I don't understand, what he actually did. What I would 
expect is someone writing R3 in R/S, so that it would got all backends 
R/S supports?

Thanks. I would expect LibReadLine to be loaded before LibHistory, 
so the fact it errored on the latter may mean that it has loaded 
ReadLine successfully. Others often try to have a compatible interface

I still prefer having FUNCTION take care of it and using simple word! 
values, else it looks odd and misleading (i: 5 looks like one expression, 
while it is two expressions in fact).

EXIT and RETURN have been implemented for the interpreter too now. 
All related tests are now passing. An important fact to note, which 
differs from the Rebol way:


EXIT and RETURN are dialect keywords in Red, not native functions. 
Both the compiler and the interpreter are processing them as part 
of function's body dialect.

This fact seems to show that Samsung really is doing things in a 
non standard way ... at a very low level may be !!!

this will create an eternal pressure from technical people to make 
Red 0 based

 In fact, I've decided since a while to add PICKZ and POKEZ to Red 
 so 0-base algorithms would be more natural to implement. I need to 
 add an entry in Trello about that or I will keep forgetting about 
 it...

@james_nak, thanks for testing. Your issue is probably related to 
the fact that the output area in this demo has a fixed height, so 
it probably is a bit out of screen on your device, that's why you 
can't see the first output value.

james & kaj: I have JDK installed too, you should be sure, that you 
can call java, javac from whatever dir = it is in the system lookup 
PATH. And - Rebol was downloading supporting tools, then it hang 
in console, but in fact, there was a dialog box hidden in the background, 
asking me for write permission. Unless you allow that, the tools 
are not going to be saved into requested directory ...

or anyone else... in fact.

I have nothing against R/S, in fact - I am liking the overall Red 
architecture. I somehow can't explain it, dunno. Simply put - I worry, 
that basing my programs upon some already existing bindings is risky, 
as Red will provide its own solution later, which will make it incompatible 
imo ...

you know, for our Led screen, I wrapped the dll using r2, red/system 
and world. In fact, it was rather easy to switch. If there is at 
least some level of compatibility, I like the options ...

Fork said, that Carl said, that if he would be about to rewrite Rebol, 
he would took R3 aproach ..

 Fortunately I was there so I can give some contextual information: 
 Fork was saying to Carl his famous quote: "Rebol4 is Red". What do 
 you expect Carl to reply to that? ;-)

I hop Doc is not going to be (de)motivated after ReCode.
 No, it's the opposite in fact. ;-)

in fact I've got one solved at 5 mirrors... darn, adding two extra 
mirrors without affecting otheres is *hard*

to me the issue is not as much about if I Can USE R3 as much as if 
I can safely play with it.  using any GPL based license, looking 
at R3 sources becomes a big problem.  


in fact, just looking at its mezz code becomes an issue.  I can't 
see how R3 will fit my development needs.

'or we could get a FAQ entry declaring that the functions built into 
R3 are "part of the interpreter" rather than "library code"' - that 
is where I do agree with you, except for the fact that we do have 
such an indication:


1) the functions *are physically/* part of the interpreter, they 
are "linked into it" (I would say "statically", since the interpreter 
does not need to look for them "elsewhere in the system", they are 
"inside")

2) the functions are a part of the interpreter, the interpreter documentation 
specifically mentions the functionality of the interpreter (the documentation 
mentions that the "ordinary version" of the interpreter "understands" 
FUNC, DO, PARSE, whatnot...)

Bad comparison. Functions linked into GCC are not used by user programs.
 - that is false, in fact. For example:

double j = 1.0 + 1.0;


is being done by the compiler, because the compiler is able to do 
it, not needing to link in any function to do this at runtime.

Ladislav - in 2004, when R# was slowly taking off, Carl published 
a blog article or announcement, describing R2 plugin feature. The 
supposed release was "imminent". Prior to that, Carl even contacted 
Doc to eventually stop working on R#, or so I remember. Of course, 
the announcement was just to distract ppl from alternative, keeping 
them interested in REBOL. 


Later on, I several times rightly identified some blog-post, whose 
purpose was nothing more, than to buy some time for RT, where in 
fact promissed things were not delivered. 


So - of course it is just my speculation, but with the history of 
R3 development I find it really curious to try to hype users to believe, 
that port to ARM could happen in 5 minutes, when RT was not able 
to deliver it is 5-6 years of R3 existence? And if so, it sounds 
a bit unfair to me ...


Simply put - wish Red, R3, World, whatever clone a success. It is 
just that what I would like to see is - a realistic estimates on 
any side ....

in fact, it is even worse - GUI is done for quite some time, yet 
no new styles/skins appear, so nothing to complain here about - anyone 
of us can contribute. I just somehow don't believe, that yet-another-fork 
will make situation any better ....

sqlab, the fact that the "average Rebol user is just to much individualist 
to join" has always been a curiosity to me.

The original demand was to have a /FLAT version which I offered to 
add, but Robert asked me to modify /LINK behaviour instead. I do 
not mind, in fact.

...but the fact is that adding another refinement would complicate 
the interface a bit without being absolutely necessary, perhaps

This is only partly true.


It is in fact faster to SHOW the whole window, rather than calling 
SHOW multiple times for single elements, when there are sufficiently 
many elements in the window. Still, SHOW also depends on the size 
of the area to display, so if you have, say 10 fields, wrap them 
in a PANEL style and then perform the SHOW on the PANEL instead of 
the whole window or the individual fields.

welcome to Rebol John, 


this group's etiquette is: "there are no stupid or wrong questions".


In case you ever wonder if you are asking too advanced questions 
at some point .... the fact that you are thinking of asking them 
here is an indication that you're still a candidate for this group 
 :-)

Graham: Thanks. That makes sense out of something someone else told 
me. I thought the information was contradicting what you guys said 
earlier, it just means I misunderstood the order of things. The modiffer 
after the slash is closer to making a new command than it is an agrument 
than I had envisioned. The fact that random is part of both made 
me think they could be done together. Thank you for catching that 
I did not know that detail.


 Next part of myscrip enters something into a database. The server 
 will have an mySQL database installed. It is possible that alternative 
 could be used, but knowing for sure I have at no extra charge this 
 options means I am starting with this option.


 So I found a MySQL Driver for REBOL from here: http://softinnov.org/rebol/mysql.shtml


 I am following the instructions that came with the download. Is there 
 anything I should know. Maybe it is not the driver people use because 
 there are better ones. Maybe the author kills kittens on the weekend 
 and it is consider bad form to use it. Maybe it is harder than it 
 looks. Basically, please just tell me if there is general info about 
 it I should know that is not obvious. Thanks.


Hey, someone else is asking questions? i thought this was all about 
me! :-) :-)

The principle is that the token calculated that way:

1) depends only on now/precise, in fact

2) since there are the is the RANDOM/SEED and RANDOM calls, it is 
still possible that in some cases distinct NOW/PRECISE results lead 
to the same TOKEN value

The second thing is the validation I have in mind is in fact a client 
side Javascript/jQuery script before sending the form.

have you written a paper on GC in Rebol ?

 - the reason why the function persists between presses in R2 is based 
 on the fact that USE modifies its argument block "leaving" the local 
 variable in it. (it is described in Bindology). In R3 USE is a closure 
 written in REBOL, that is why there may be some "persistence" until 
 the USE function is called next time

You are OK, most probably, but not due to the fact that USE is not 
modifying, rather due to the fact that it most frequently does not 
matter.

Marc, your "private variables" like 'with, _recur_ can be made more 
private not needing to use the PROtECT function, in fact.

The fact is that the CATCH/NAME+THROW/NAME pair is not ideal for 
this, but I do have a function which might be able to handle even 
the G/RECUR case.

If you use foo: [], you can.


There are perfectly legitimate ways to use the block that way. You 
should simply be aware of this fact, when assigning the word to that 
block.

just about every time I've had to fix something with VID it was related 
to the fact that redraw is being used.  its a very bad design... 
redraw should never have been put into the feel.   its also a big 
slowdow, since it forces every face to redraw itself when you show 
a pane.

it may in fact refer to some part of the RFC which prohibits character 
0 from URLs (which I am guessing is the case, haven't read that RFC 
for a time).


 in this context, it makes sense to leave it there, but if using dehex 
 for other purposes its annoying.

What I am still afraid of is the fact that the "Closure" name could 
scare beginners looking sufficiently "unfamiliar" and "exotic", while 
I think that what *should* scare beginners as far as the behaviour 
is observed is actually "Function".

Neither INSERT nor APPEND modify the index attribute of their argument 
(the index attribute of series is immutable, in fact)

#[[DIdeC
str: "abcdef"

==> Create a string! in memory, put "abcdef" as its content, create 
a word! 'str an make it point to its head.
]]


- that is not true, in fact. The proper description is as follows:

    str: "abcdef"


is a Rebol source (or a part of it). That source is first processed 
by LOAD. LOAD creates the Rebol value representing "abcdef". Also, 
LOAD does *not* set the 'str value (yet).


Later on, when the DO function evaluates the (already LOAD-ed code), 
it just makes the 'str variable to refer to the string value not 
creating anything at all (this difference is crucial).

Simply put - millisecond lock time is enough fine grained for my 
purposes, but - let's assume you have several ppl working on some 
customer list, where each customer has some orders. Those ppl do 
select particular customer, and work with orders. What I want is 
- when some user selects particular customer, I need its record being 
locked. The trouble is, that when I use BEGIN transaction for sqlite, 
it locks all the file, and does not allow other process to do write 
to the DB.


I wonder, if I can somehow obey it, not really having per record 
locking. I would have to implement my own lock mechanism (not locking 
in fact), not allowing others select/enter customer record, when 
some other person is working on it?

Even Cyphre doesn't want to use it anymore, for technical reasons

 - I never heard anything like that, and it even does not correspond 
 with my info, that in fact Cyphre would like to redo the View engine 
 completly ...

But other engines you name are far from what View engine in fact 
is - system of gobs, etc. Widgets are VID. I still prefer not so 
much perfect VID, instead of overbloated stuff ...

Now we can attend to the things that were elegantly conceived but 
never really developed.  MDP is one example.  I like the exclusivist 
nature of Rebol.  I like the fact that I can do my architecture from 
back to front without ever leaving Rebol.

Hmm, I think you are in fact mixing up implementation with syntax. 
Are you saying that MakeDoc markup is not something that can/should 
be able to be processed by non Rebol tools?

The value 0.1 can't be precisely represented as an IEEE754 64bit 
floating point value, it can only be approximated.
 - yes, correct!


However, if you write 0.1 in Rebol, the interpreter (the LOAD function, 
usually) "understands" it somehow. What I said is that nobody doubts 
that the string "0.1" can "accurately enough represent the (above 
mentioned) Rebol value", not that the "Rebol value accurately enough 
represents the string" (I did not even define  what that means).


'When MOLD just uses 15 digits, it outputs "0.1", which may be what 
you entered, but not what is in memory. What is in memory is 0.10000000000000001, 
so if you have MOLD autoexpand the number of digits it uses then 
MOLD 0.1 will output "0.10000000000000001".' - actually, the number 
"in memory" (it does not matter where the number is, in fact, what 
matters is just that it is the IEEE-754 64-bit binary floating point 
number representing "0.1" in accordance with the IEEE-754) is 0.1000000000000000055511151231257827021181583404541015625 
in fact.

The fact is that, e.g., "0.1" is not accurate when you *want* 17 
digits of the number, but it is "accurate enough" when my definition 
of what "accurate enough" means is used.

It is possible to prove that Rebol identity does not depend on the 
SAME? function at all, in fact, and unsetting 'same? I obtain the 
same identity as when the SAME? function is defined.

(which is what the article demonstrates, in fact)

BrianH: I think we should change the /GZIP refinement to /CRC32 so 
it is independent of the format. Then we can create mezanine/scheme 
support code for various higher-level formats (ZIP, GZIP etc.) at 
the REBOL scripting level.

BTW I have finally fixed the current /GZIP refinement problems so 
now I'm able to ZIP/UNZIP uzing rebol script without the 'PNG load 
hack' that is on rebol.org. In fact I modified the rebzip.r to work 
with R3 and the ZIP/UNZIP operations are now "instant" when comparing 
to the R2 version. So I guess this is a good proof we can write fiast 
zip:// scheme with just the current COMPRESS/DECOMPRESS natives.

In fact, that sort of thing turns people on when they hear of your 
drive and success

<Complete package ...etc> It's interesting that the fact that REBOL 
would have many schemes was part of the original vision / marketing:

   http://web.archive.org/web/19980530155104/http://www.rebol.com/news.html

I gave the

    for i 1 2 0 [prin "x"]


a second thought, and the fact is that the "forever" functionality 
looks legitimate as well. Thus, it would be best if we made a user 
poll to find out what is preferred. Whether looping forever or not 
looping at all. So, please, let us know what do you prefer.

i.e. C language for () is not a FOR loop, in fact. it is a general 
loop

Ladislav, that's a feature list, not a dialect.

 - sure, feature list is not a dialect. CFOR is a dialect, though, 
 exactly like there is an object specification dialect or function 
 specification dialect. The fact that you do not see it is a dialect 
 does not matter at all

It was just this one case, which I think differs from Brian's model.

 - that is not true, in fact. Brian stated arbitrary rules like "for 
 i 1 1 whatever [...] should loop exactly once", that is a difference 
 as well

The fact that we even have a FOREVER loop at all means that there 
would be a value in having developers use it, just for their own 
documentation.

You can say that you "support" zero velocity by "not looping", but, 
in fact, you rather don't support it by failing as silently as possible.

No, you have not, in fact (at least IMO).

I haven't had the time to follow all the discussion in detail, but 
to me, the second part of split-path should NEVER return a directory 
path. 


when doing   set [dir file]  I should be able to count on the fact 
that the second part is either a file or none.  The same for the 
first part which should always be none or a dir.  I have my own implementation 
in R2 which makes this strict and it simplifies a lot of code.
so we can do with absolute certainty:

if second set [dir file] split  path [   ]


IIRC some of the versions of my split perform a clean-path to simplify 
and add robustness to the result.

hmm, I may be wrong in "it does not violate anything" - in fact, 
it contradicts the help string of the function

I think ppl in kind of an wait mode. Some interested in Android in 
general, some interested in Red progress, som interested in Ren, 
most of us busy other way.  Max in fact is doing a good job - he 
tries to use the system in a practical way. My questions are just 
theoretical, just by reading docs and looking into the code. I know 
I will be back to GUI at some point, just dunno when ...

Well, but the fact that REB_FUNCTIONs don't need GC is not ugly IMO.

Clarification: as far as I know nobody plans to change the implementation 
of the datatype. However, it is not money in fact, it is actually 
better characterized as a decimal datatype. That is why I did not 
understand why did you suggest any new decimal type since it already 
exists using just an inadequate  name.

or maybe adequate... The fact is that the syntax corresponds well 
to the money! name, and it makes sense to keep the syntax as is.

in fact, maybe the new float! could support NaN, +/- inf, etc    
 while decimal would continue to raise a bit more errors.

Actually, Oldes, that's a great idea!  R3's new GUI could be built 
to utilize OpenGL by default.  That way, the GPU would handle all 
the graphics calls, and R3 would have 3D capabilities built-in as 
a bonus!  This would probably even make porting to Android and other 
platforms a lot easier.  In fact, doesn't IOS (iPhone) use OpenGL?

Bo, I think if we don't make drastic changes to the GOB mechanism 
we should be safe when building anything on top of the GOB datatype. 
The gob! is in fact abstraction layer between the "VIew engine" and 
any "GUI framework" written in REBOL.
So as take this example:

We have now R3GUI framework which runs quite well on the current 
View engine (although this engine was build in 2 weeks during the 
very early R3 alpha work so it's kind of Q&D prototype ;))
(BTW should I mention the R3GUI is much better than R2 VID?)

Anyway, the R3GUI works on current View engine. When I tried to change 
the engine so it uses OpenGL accelerated AGG the R3GUI still worked 
without any problem (except visual bugs caused by incomplete OpenGL 
code implementation of the new prototype).

SO from that example you can see the "View engine" and "GUI framework" 
are two independent things and can be developed or even exchanged 
separately.

I had the r3 hostkit running as a dll with full host support... in 
fact, I was able to execute R3 scripts from within R2   :-)