World: r3wp

Consensus adds to the strength of an argument. Chiming in with an 
"I agree with Ladislav" on a potentially controversial issue reduces 
the controversy that might otherwise block it, especially if you 
are sometimes someone who disagrees with Ladislav effectively (which 
is pretty difficult to do).

This has worked very well before with CureCode tickets and such. 
If Carl doesn't have a strong opinion either way, he will wait for 
consensus.

Back to QUOTE and get-word arguments...


We need something like QUOTE, especially for set-*, *-paths, and 
functions, because these block an evaluation that may have side effects, 
or at least cause a value copy. Even if QUOTE is the only function 
with this evaluation model, it depends on DO supporting something 
like get-word argument evaluation in order to work at all. The alternative 
is to make 'quote a keyword in the DO dialect, which decidedly doesn't 
have keywords. So we can't get rid of get-word arguments altogether 
without ridding ourselves of QUOTE, and you'd get a bit of resistence 
from anyone who's used it if you want to do that.

If you want a SECURE 'get-word constraint that you can apply after 
QUOTE is defined, that will block some but not all function hacking 
attempts using function values. The "but not all" part is critical 
though, so we are better off from a security standpoint if developers 
aren't allowed to think of function values as being safe to call 
without precautions, since the consistency of the need for that precaution 
makes it more commonly applied.

Is this because string implementation isn't finished?

>> next "abc"
== "^@^

Maybe related to UTF?

This is on OSX? If yes, it's probably this bug http://curecode.org/rebol3/ticket.rsp?id=1870&cursor=1

Yes, on OSX. Thanks!

Are we still alone ? No news from/about Carl ?

Carl posted in that bug at 22-Mar-2011.

Carl's latest REBOL blog is dated 28-Mar-2011:
http://www.rebol.com/cgi-bin/blog.r

So seem to be 1 month 2 weeks since last REBOL blip.

They are all information I have. I monitor those channels.

We are still at buil A111

Yes, and I don't put my expectations up. But I feel, people are hard 
at work with alternatives to REBOL.

RED...

That's one, yes.

It is great but a Waste of time. If only REBOL was open sorced DOC 
could put his offorts on it.

Insteda we are reinventing the wheel

If the first wheel can't run, reinvension can be a good thing.

Think "reinvention" is with a t.

Also with all other languages, you have more than one implementation. 
I don't think, all those are waste of time. How many different C 
compilers have been made over the years?

One of the nice things about Red is that it's not really the new 
wheel, but quite different

Still, I wonder why people object so strongly against new wheels. 
Do you employ wooden donkey cart wheels on your electric automobile?

Yeah, there might come many new great developments from some of the 
REBOL ideas. Some of them will be very much like REBOL, but others 
will be something new.

Like all good operating systems are strongly inspired by Amiga

Red, I think, could complement R3 quite well.

would it be possible (in general) to encapsulate the whole R2/3 GUI 
functionality incl. antigrain etc. into a lib, usable for other languages 

 as a out of the box GUI generator? communication & event handling 
 e.g. via TCP?

R3 is that lib

However, it still fails to be as easy to integrate as for example 
a 0MQ library

I've been out of the loop here the last few months but it seems like 
R3 is stalled again. And I do not see any signs of Carl. What's the 
overall status here?

there has been a lot of work going on with a few R3 projects.  a 
few extensions, the gui, etc.

there has also been quite a bit of work done on Red.

Any HAM-Radio guys here? Maybe this is the best channel to get in 
contact with Carl.

:D

My brother did it in the past, but sold the equipment. I really wonder, 
what are Carl's thoughts, as even my dog understands, that REBOL 
situation is in deep .... :-)

I notice ++ and --, which was discussed here:
http://www.rebol.net/cgi-bin/r3blog.r?view=0057#comments

Would it be ok to let NEXT and BACK do the job, like this:

next: func [series] [
	either word? series [
		set series system/contexts/lib/next get series
	][
		system/contexts/lib/next series
	]
]

Examples of use:

>> blk: [a b c]
== [a b c]
>> next blk
== [b c]
>> blk
== [a b c]
>> next 'blk
== [b c]
>> blk
== [b c]

it would break a lot of code, and in fact, I prefer it like it is. 
  


this being said, if we have ++/--, then I expect *these* to work 
as you just depicted

WIll it break code? Hmm, what kind of code?

all of my code  ;-)

I don't see how. Notice, NEXT in my example works just like today 
with all arguments beside words, which gives an error today.

The first part of my examples above use the new NEXT just like the 
old NEXT, we have today.

ahhh.. I just re-read your code... and was bitten by the lit-word 
evaluation again.

I didn't realize that:

either word? series [

triggers when you give a lit-word.

in this case, you are right.


except in implementation.   words carry their binding, you don't 
need (in fact shoudn't) acess it via system   

set word next get word

should be enough.

If just using NEXT instead of full path, R3 will create a stack overflow. 
The function is called NEXT, you know! ;)

But anyway, this should be changed in the native.

I guess, the reason for the stack overflow is that function body 
is rebound to local context.

ok... I just hit myself on the head a few times.  clearly, I'm not 
sharp right now.  :-)

Winblows mess with your mind! Save yourself! :)

yeah, I guess that's it.  my brain is getting fried by the sun going 
through the windows (our first full week of sun in months).

Geomol, the return values of ++ and -- are different than those of 
NEXT and BACK, which is why we have the seperate functions.

NEXT and BACK are also non-modifying (except for ports), which is 
another valuable difference.

Are you sure, that's why we have separate functions? What benefit 
is there from the return values of ++?

By "valuable difference" I don't mean that one or the other behavior 
is preferable all of the time and so we should choose one, I mean 
that both patterns of behavior are valuable in different circumstances 
and so we need to support both. Both sets of functions are needed 
in mezzanine code, as they are now.