World: r3wp

if=

nice idea, maybe if< ?

What about a polymorphic function ?


if=: func [:sw :gw :op val][op: get op gw: get gw if (gw op val) 
[set sw gw]]

>>a: 1
>>b: 5
>>if= a: b < 10
== 5
>>if= a: b < 5
==none

aha, that is just for R3, as it looks

(and behaves in a little bit different way)

the same goes for R2, a little different though...

yes, it can be backported

but honestly i don't see the gain with that mezz.
if b < 5 [a: b] 
...is short enough and syntaxly less obfuscated.

Ladislav and Steeve, that wouldn't be the same.  Your ownly showing 
the same functionality.  What I'm talking about would require changing 
the tokenization and parsing to give the EXACT feature I requested.

Steeve also your last expression should this if your trying to capture 
the same mezz    if a < 5 [b: a]

But since I see no way that the exact expression capability that 
I desire will be implemented then I am like Steeve and say just leave 
it as is.

Paul, aha, you do not like the prefix form, and insist on the infix 
form you wrote. Then I have a surprise for you: it isn't REBOL Do 
dialect, since the Do dialect does not allow the infix op to take 
more than two arguments. Nevertheless, you are totally missing the 
point stating, that it would require changing the tokenization - 
that is patently wrong.

Sure it would be - just do a TRACE and you will see that it has to 
be changed.  Do evaluates - it has to be supplied the correct structure 
in order to evaluate correctly.

It cannot help you state that. I can prove you false if I decide 
to do so.

Prove me false ladislav.

I'm not Ladislav, but ...

Paul, you want `b: a < 10` to roughly behave like `b: either a < 
10 [a] [b]`, if I am not mistaken.

If so, such a change would neither affect tokenization nor parsing 
in any way:


That's immediately obvious when you consider that `b: a < 10` is 
just syntactic sugar for `set 'b lesser? a 10`. You surely will have 
no troubles to write appropriate `my-set`  and `my-lesser?` according 
to your desired behaviour. With that done, the only change necessary 
to implement this as default behaviour in REBOL is to use your set 
and lesser? (etc.) implementations instead of the current ones. Tokenization 
and parsing needs not be touched.

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