World: r3wp

Word-active values - another one is the #[unset!] value, which is 
also actively interpreted (triggering an error).

Regading the word-activity of lit-words - it has been quite some 
time when I suggested to Carl to make lit-words "normal" in this 
respect, but he did not accept my proposal, so I expect he found 
it uncomfortable for some reason.

Breaking some scripts maybe?

yes, aggressive evaluation of lit-word types is very annoying, it 
easily provokes molding/loading errors if you're not carefull.

yes, As in I agree with Lad

My func is very similar to yours Max.

>> x: [16#ffffff] 
== [#6#ffffff]

how can i specify an integer! in hex format?

debase/base "ffffff" 16  returns a binary! which i mostly can smear 
on my hair, since most operators just doesn't play nicely w it...

same problem again... i tried to use rebol for byte level processing 
and it's just not suitable for it.. :/

imean not logical neither easy to remember.

would it really be a pain to support the usual 0xff format?... it 
doesn't really clash w anything i think. only numbers can start w 
zero anyway...

R3 is much easier to use with binary than R2.

just use a binary string.

>> to-integer #{ffffffff}
== 4294967295

thx

0xff format
: it does clash with the pair! datatype.

true.. damn :)

on the other hand:
>> to-integer #ffffff              
== 16777215
>> to-integer #{ffffff}
== 16777215

the issues is sort of a syntax sugar, the binary string is the actual 
value in ram.   so you can do things like:

a: #{0f0f0f0f}
b: 3520188881     
>> a and b
== #{01010101}

but you can't with issues:

>> b: #d1d1d1d1
== #d1d1d1d1
>> a and b

** Script error: and does not allow issue! for its value2 argument

but if u have to turn it into integer anyway, then the issue is shorter

the only  real thing to be aware of is that to-binary of an integer 
will give you a 64 bit binary!

>> to-binary 22
== #{0000000000000016}

here is my ObjectID routine a'la mongodb.

wondering how much simpler could it be in r3?...  not that i could 
use r3 any time soon for production stuff, but i would love to, of 
course

  rejoin probe reduce [
    to-hex date-to-epoch now

    enbase/base copy/part checksum/method system/network/host 'md5 3 
    16
    skip to-hex access-os 'pid 4
    skip to-hex random/secure to-integer #ffffff 2
  ]

Geomol, the ticket for the lit-path problem you mentioned is here: 
http://issue.cc/r3/1434

Brian, the ticket you mentioned is not related to the problem Geomol 
mentioned.

Question: how many REBOL users prefer:

a: make object! [b: does ["OK"]]
a/b ; == "OK"
do 'a/b ; == a/b

versus

a: make object! [b: does ["OK"]]
a/b ; == "OK"
do 'a/b ; == "OK"

?

I prefer the latter

(seeing it as more convenient)

latter

And, how many users prefer:

a: make object! [b: does ["OK"]]
type? do in a 'b ; == function!

versus

a: make object! [b: does ["OK"]]
type? do in a 'b ; == string!

I prefer the latter again

The latters seems more logical to me in both cases.

The latters seems ok to me. But what if w is a word holding 'b or 
'a/b, as I was testing, in relation to the object a? This is what 
I get:

In R2:
>> a: make object! [b: does ["OK"]]
>> w: first ['b]
== 'b
>> type? :w
== lit-word!
>> a/:w

** Script Error: Invalid path value: b	; To me, that error is wrong 
worded, it should show 'b.
>> in a :w
== 'b		; Confused, as a doesn't hold any 'b
>> do in a :w
== 'b		; Why?
>> type? do in a :w
== lit-word!

Same in R3:
>> w: first ['b]
== 'b
>> type? :w
== lit-word!
>> a/:w

** Script error: cannot access :w in path a/:w		; Not sure about 
this error. Could be better, I think.
>> in a :w
== 'b			; ?
>> do in a :w
== b			; ??
>> type? do in a :w
== word!

And now the 'a/b:

In R2:
>> a: make object! [b: does ["OK"]]
>> w: first ['a/b]
== 'a/b
>> do w
== "OK"
>> do :w
== 'a/b

In R3:
>> a: make object! [b: does ["OK"]]
>> w: first ['a/b]
== 'a/b
>> do w
== 'a/b
>> do :w
== 'a/b

wrt:

And, how many users prefer:

a: make object! [b: does ["OK"]]
type? do in a 'b ; == function!
versus

a: make object! [b: does ["OK"]]
type? do in a 'b ; == string!

============================

the first should be supported via the 'GET word, so I'd say the later 
is better, otherwise, there is no point with 'GET. 

basically, this was perfect in R2, why did it change in R3?

seems like a bug

It changed because functions were getting executed when you were 
doing a word referring to a function, rather than doing the function 
itself.

Ladislav, that ticket was related because it explained that lit-words 
were active values and that the behavior was intentional. This can 
be changed if we decide differently, but it isn't currently a bug, 
it's intentional.

I understand that the change was intended, but currently, all the 
respondents prefer the original behaviour.

And no wonder they do. If a user calls the DO function, then it is 
expectable that functions, etc. get evaluated.

Yes. But that is doing the *function*, not doing a word that refers 
to the function.

It's the difference between a: :print and a: 'print.

As said, all the respondents above prefer the function to be evaluated 
when doing a word that refers to the function. The only way how you 
can influence it would be if you said you preferred the current behaviour 
as implemented in R3. Do you?

For that, absolutely. For the lit-word/lit-path thing, no.

I hope we get more answers, since it is weekend now.

http://issue.cc/r3/1881and http://issue.cc/r3/1882submitted

Regarding the example evaluating words above:

    lit-path: first ['a(b]
    do [lype? lit-path]


Which result do you prefer? As far as my preferences go, I prefer 
to obtain the lit-path! datatype

Correction: Regarding the example evaluating words above:

    lit-path: first ['a/b]
    do [type? lit-path]


Which result do you prefer? As far as my preferences go, I prefer 
to obtain the lit-path! datatypeRegarding the example evaluating 
words above:

    lit-path: first ['a(b]
    do [lype? lit-path]


Which result do you prefer? As far as my preferences go, I prefer 
to obtain the lit-path! datatype lit-path: first ['a/b]
    do [lype? lit-path]

This keyboard is getting me crazy, sorry

Correction: Regarding the example evaluating words above:

    lit-path: first ['a/b]
    do [type? lit-path]


Which result do you prefer? As far as my preferences go, I prefer 
to obtain the lit-path! datatype

(in R3 yout get the lit-path!, while in R2 the path! datatype)

I prefer lit-path!. The same for lit-words:

	lit-word: first ['a]
	do [type? lit-word]


I prefer that to return lit-word!. It's only, if the word being looked 
up (lit-word in this example) is a function (or native, op, action, 
...) that further computation should occur, I think.

Makes sense

Actually I ran into problems related to this, when programming the 
bparse function. At one point, I need to test, if a token variable 
is equal to the word END. To specify the word END, I write it as 
a lit-word, because lit-words are changed to words on the run. I 
need to use == to compare, because I want the type to be the same 
too. So I would expect, this is the correct test:

	token == 'end

Let's test:

>> token: first [end]
== end
>> token == 'end
== true

Seems to work, but then the surprise, if token is a lit-word:

>> token: first ['end]
== 'end
>> token == 'end      
== true

Also true? Hmm, so I have to write:

>> :token == 'end
== false

The above is done in R2.