World: r3wp

See that is NOT what I requested.  I didn't request to use another 
set.  I requested to use the current ones.

It isn't just limited to <

It could also be:
b: a - 3 > 11

Or get much more complex expression that involves logical evaluations.

Introducing other functions is not what is being requested.

Again it would REQUIRE new Parsing to accomplish the task.

Again, `b: a - 3 > 11` is syntactic sugar for `set 'b greater? subtract 
a 3 11`.

No parsing changes needed for that either.

(Just changes in the implementation of set, lesser?, greater?, equal?, 
etc.)

No change in syntax or parsing would be required. However, the DO's 
evaluation rules for the set-word expression *would* need to be changed. 
Note that these evaluation rules are *not* performed by a parser, 
so changing parsing would not be required, Paul.


However, this change to the evaluation rules of the DO dialect would 
be so fundamental that we would essentially be changing the semantics 
of the language to that of another language. And that other language 
would resemble Icon more than it would REBOL, semantically. And changing 
the behavior of the SET, LESSER?, ... functions would not be enough 
because DO doesn't actually call those functions directly - it calls 
internal code, which may or may not also be called by those functions.


But this is not a problem, because at least you wouldn't have to 
change the parsing. This means that all you would have to do is write 
your own evaluator and pass the code to that instead of DO. And create 
new versions of all the functions that call DO internally, behaving 
the same but calling your DO replacement instead. And create a context 
to reference those functions, and bind to that context instead of 
the standard system context. Basically, all you have to do is create 
a new dialect on the scale of the DO dialect, using the same REBOL 
parser, but different semantic rules.

`b: a - 3 > 11` is *not* syntactic sugar for `set 'b greater? subtract 
a 3 11`, instead it is sugar for the internal code that those functions 
call. So changing the meaning of those functions wouldn't be enough. 
To really make the change, you would have to replace DO. But not 
completely, because all of our code depends on DO remaining as it 
is - so you would need to make a new sort-of DO-like dialect that 
would be used in addition to DO, for those circumstances where you 
need this semantic model. Just like any other additional dialect, 
really.

On the other hand, if you want to change DO's behavior to this, then 
it would require you to create a *new* language, with the same parser 
as REBOL, or one that is completely compatible. Basically, an incompatible 
REBOL clone. It would be hard to use the same parser though because 
the existing runtime code depends on the current semantics, so you'd 
have to replace that code too.

So the reason that we were suggesting functions instead of core semantic 
changes is because the function solution is feasible, while the core 
semantic changes are not without remaking the language. And the function 
solution gets the job done, though not as efficiently as the existing 
function solution: IF.

i don't find parse-xml in r3 !!!! why ?

Perhaps Carl has not had time to test it under R3, so it is not properly 
certified.


Superficially, parse-xml seems to work under R3......If you had the 
time to do some more comprehensive testing, that may encourage Carl 
to make it part of the official release.

To export parse-xml from R2 and import it to R3:

In an R2 session: [r3-path] is the path to your r3 executable

    save %[r3-path]/xml-language.r join "xml-language: " mold xml-language

    save %[r3-path]/parse-xml.r    join "parse-xml: "    mold :parse-xml

In an R3 session:
    do load %xml-language.r
    do load %parse-xml.r

Prove me false ladislav.

 - I do not want to, having observed other people to do just that 
 without their effort being of any observable help to you.

(do not forget, that it would require a nonnegligible effort, from 
me, which I can use for more sensible purposes)

Not to mention, that it is you, again, who makes false statements 
not substantiated by any sufficient reason.

And, BTW, I neither like nor need the functionality you proposed.

What is the state of HostKit? So View has partly moved outside of 
the Core, but - it is usable? Anything to test? All we got so far 
is stripped down to Core R3 release :-)

I think only Carl knows.

pekr... stripping view out of core and making it work again is probably 
the most complex task Carl has had to do since he's been working 
on R3.


it means he has to formalize quite a few of the core as official 
APIs which he didn't need or intend to do at first.  He  didn't  
*design*  the core with view extraction in mind.  it was a far distant 
goal... as in "someday we could extract view and make it an extension".

other things have been tedious work, but more linear and just implementation 
(unicode support comes to mind here) ... extracting view is all about 
breaking things, and making them work again.  adding bridge code, 
making sure once internal code is safe for use by the outside.  carefull 
planning of design so its improvable.  Correctly naming things which 
internally didn't have to be named so specifically.  


 these things really are a lot of headaches cause there are a lot 
 of decisions to be made which have dire and far reaching consequences. 
   its not just a question of "does it work".

Claude, the R2 mezzanine source, including PARSE-XML, is in DevBase 
(aka R3 chat). It shouldn't be too difficult to adapt it to R3, for 
a library module. It would probably be a bad idea to include it in 
R3 as mezzanine though: History has shown that most people don't 
need to parse XML, and the ones who do usually need to parse XML 
differently from how PARSE-XML does so, and differently from each 
other as well. This kind of situation is what the module system and 
community libraries are for :)

Yeah I didn't think so Ladislav.

i was reading doc about moblin now meegoo os and i was stunned to 
learn all their gui where based uppon QT  &and ...

intensive suspense

thank you Sunanda and BrianH. i will test it

JAVASCRIPT

why not rebol ,,, serriously if you have to fall that low as using 
javascipt + QT for you gui only to say we do quick qt developpements 
why not using rebol?

and rebol would be the perfect match  for a light weight extensive 
os like meegoo more the  time pass and more the oportunities to make 
rebol find it's way out are wasted  one after other

the actual big rush in computing area is all in one webrowser no 
such deferencies like local or distant applications will exists anymore 
and in a way rebol/desktop was pioneer in that scope

where are we 10 years later ?

http://meego.com/community/events/presentations/rapid-development-meego-using-qt-quick

that's what marvelous things the industry is coocking while we are 
endlessly stuck in alpha stage

but at same time what happend in R3 project is somewhat some of the 
coolest thing I ever seen a true complicity is rising between carl 
and rebolers. unfortunatly that's not the kind of things easy to 
communicate around. but yes 3 years of alpha stage because the reboler 
community really involved in the creation bringing at every steps 
their comments  etc ... so it's arsh to say that's a fruitless tree 
of efforts

Max... I'm curious... how do you know that Core was not designed 
for View to be extracted? Did Carl tell you this or are you guessing? 
Because, you know, Core was developed by Carl and View by Cyphre, 
and Cyphre never had any access to the Core sources.

Which makes me wonder about this separation because there's always 
been a core product

Gabriele - Max is imo right, sorry. I screamed for proper "componentisation" 
of REBOL since 1997. I requested there would be only one kernel (rebol.exe), 
and the rest being loadable components ...

What Max is describing is changes to API in core, in order for View 
working as an extension. It is not just the question of stripping-out 
View related functionality, but to create Core API, which can communicate 
with View extensions (or the other way around). But you know that 
for sure, as you know architectures better than me surely ...

View was not developed by Cyphre. Original View was developed in-house, 
by Jim Goodnow (Carl's friend from Amiga days (author of Aztek C, 
or something like that). What Cyphre did was adding AGG in there. 
Cyphre often tested AGG functionality in form of a DLL, externally 
then Carl patched it in into View IIRC.

Petr, being separate as a separate binary is a different concept 
than being a separate module in the code. View has always been "optional" 
even in R2. Having it as a separate binary means that you need a 
way to "load" it, and that's not trivial if the external part has 
to be able to call in to the internal part.

but, I don't think this is necessarily the issue here. The issue 
is just that the design is being move from being more interdependent, 
and based on DELECT, to being more abstract and independent and based 
on commands.

this is a lot of things to change in the code, but I disagree it's 
a big difference design-wise.

IIRC even for R3, while Cyphre has access to View sources, he does 
not have access to Core sources. So the final integration still has 
to be done by Carl. That is my understanding. That is why Cyphre 
is waiting with some improvements, for Carl to finally externalise 
View, so that we don't have to wait for Carl anymore to patch things 
in ...

Petr, R3's View does not share anything with R2 View AFAIK

So you were talking R3 only?

of course.

I wonder what happens to DELECT itself. If we will use command interface. 
Will DELECT still be any usefull?

R3's View has always been "external" in the sense that it was in 
the host side. I have seen its sources. the interface between host 
and rebol dll (core) has gone through a couple redesigns (starting 
with the Unicode changes), but in principle View has always been 
"separate".