World: r3wp

If allowing get-words in spec blocks, then QUOTE is fine. I'm questioning 
allowing get-words in spec blocks. It can lead to uses as this:


I make a function, that can do a paren! (in lack of better example, 
but it makes the point, I think):
>> do-paren: [:p] [do p]
I can try it on a paren:
>> do-paren (1 + 2)
== 3
Works ok so far, so I try having a var holding a paren:
>> q: quote (1 + 2)
== (1 + 2)
>> do-paren q
== 3
I got the feeling, I know how do-paren works, until I write:
>> do-paren quote (1 + 2)
** Script Error: do is missing its value argument
Hm, what if I use the old method:
>> do-paren first [(1 + 2)]

** Script Error: p expected series argument of type: series pair 
event money date object port time tuple any-function library struct 
even...

That's confusing, as I see it. (Example done in R2.)

do-paren: [:p] [do p] - the only problem with the function is, that 
the function is so, that it can "do a paren", but only if that "paren" 
is already supplied as a value, i.e. not as an expression

reformulation: is should have said: "only if the said 'paren' is 
not supplied as a result of an expression"

I remember reading, parens are evaluated (an active type, I think 
you call it). It's a very fundamental thing. Breaking this rule make 
the code less readable. Is it really necessary? What natives or mezz 
have get-word arguments? Kinda the same with lit-word arguments (in 
the spec block). My guess is, Carl made those, so he could write:
help add
instead of
help 'add

Please, stop writing "get word arguments", they are not "get word 
arguments"

Similarly, the "lit word arguments" are not "lit word arguments"

right, what should we call them to not make confusion?

Maybe "get-word func parameters"?

they are "unevaluated arguments" in case of the QUOTE function, and 
and "partially evaluated arguments" in case of e.g. the first argument 
of the FOREACH function.

by "unevaluated" is meant "never evaluated", by "partially evaluated" 
is meant "sometimes evaluated, sometimes not evaluated"

(i didn't know about the :p where is it documented? otherwise i used 
the 'p notation many times. it even allows to add explanatory words 
to the parameters, so u can make a nice dialect by using the default 
'do evaluator...)

The R2 doc for "get arguments" is here:
http://www.rebol.com/docs/core23/rebolcore-9.html#section-3.3

thanks a lot. i thought i know the core docs in and out :)

:) I look in them now and then, as it's easy to forget many of the 
features in the language.

About unevaluated lit arguments (or literal arguments, as Carl call 
them), the functions FOR, FOREACH, REPEAT and maybe more use them 
(I couldn't remember earlier when I posted). And yes, it's more convenient 
to write
	repeat i 10 [...]
than
	repeat 'i 10 [...]


But used in some cases, it's probably easier to create less readable 
code. I can imagine a language, where this is different. About the 
other type of unevaluated arguments (get arguments as Carl call them), 
I haven't found other functions than QUOTE, that use it. There must 
be others!?

there is no LIT-LIT-WORD argument, so, to obtain a lit-word, the 
most natural way is to use: quote 'a

Some thoughts:

So one use of this is to make it easier to e.g. insert a lit-word 
in a block. I come to think of how to insert a block in a block. 
We can't do:

	insert blk [a b c]


as that will insert the 3 words, a, b and c, in blk. So I can write:

	insert blk [[a b c]]
or
	insert/only blk [a b c]


Why not use the same kind of thinking, when dealing with lit-words? 
So I can write:

	insert blk ['a]
or maybe
	insert/only blk 'a


(maybe the refinement should be called something else than /only). 
Now, the rule for INSERT should then be, that if it get a word (the 
lit-word, 'a, will be translated to the the word, a), it should change 
that to a lit-word, if it got the refinement too.


Result is, that unevaluated get arguments can be avoided making the 
REBOL scanner/parser simpler.

Geomol, if you agree with this model:
>> do quote 'a/i
== a/1
, put your agreement in http://issue.cc/r3/1434where it counts.

As for functions with get-word arguments, the DO dialect used to 
need more of them, but in R3 most of those needs are handled by QUOTE. 
For other dialects though it is much more useful, as it prevents 
evaluation by the DO dialect when it is unwanted. It can be used 
on occasion in security situations if you want to block calculated 
values. Also, it could be used in a statically compilable subset 
of REBOL for the block arguments of all control and loop functions 
like IF and WHILE.

No need, Ladislav already put it there. If that's for Carl to read 
through, it's an awful lot of information.

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.