World: r3wp

using rebol to peek inside of rebol isn't disassembling  :-)

There some differences between us Doc, you have a company selling 
rebol services ans progs. Me, I don't use Rebol professionaly

Well, only RT knows for sure how it works internally, if some info 
is disclosed, then it become public so no problem talking about it, 
 I think.

So, even if you had disassembly rebol, you can't say that

Whatever way you use REBOL (hobby or professionnal use), it implies 
accepting the EULA.

By installing or using the SOFTWARE, you are consenting to be
bound 
by and are becoming a party to this AGREEMENT. If you do
not agree 
to all of the terms of this AGREEMENT, do not use the
SOFTWARE.

You're such a boring guy Doc, i didn't know you were

I'm a guy with principles and respecting the work done by other is 
one of them. I like playing by the rules.

Ok we know now, don't push yourself

As I'm reviewing my old code, where I see a lot of rejoins where 
the first arg of block is always binary... what do you think about 
something like:
abin: func[block][append copy first block next block]
where the speed gain is:
>> tm 1000000 [abin [#{00} "a"]]
0:00:01.609
>> tm 1000000 [rejoin [#{00} "a"]]
0:00:02.938

maybe not such a big gain.. as I must use:
abin: func[block][append copy first block reduce next block]
which has result 0:00:02.078... but anyway.. every ms counts:)

mazbe it's strange that works:
>> make string! reduce ["a" "b"]
== "ab"
but not:
>> to binary! reduce [#{00} "a"]
** Script Error: Invalid argument: #{00}
** Near: to binary! reduce [#{00} "a"]

abin: func[blk][head insert tail blk/1 blk/2]

abin: func[

 "faster binary creation of a block where the first arg is already 
 binary!"
	block
][
	head insert tail copy first block: reduce block next block
]
;to be able have code like:
abin [to-binary #"^(00)" "a" "b"]

I didn't decompile or disassemble, I just used the scientific method 
to evaluate behavior.

Same way I came up with the initial documentation about REBOL contexts 
and binding back in 2000.

Everything else is based on public discussions in various chat groups.

Oldes, a faster way (in R2) is this:
abin: func[

 "faster binary creation of a block where the first arg is already 
 binary!"
	block
][
	head insert copy #{} reduce block
]

Of course the doc string would need to be changed, because there 
would be no restriction on the type of the first expression.

you are right.. thanks:)

how zou would call it?

bjoin, since it is a binary version of ajoin.

bjoin [#"^(00)" "a" "b"]

What do you see as the arguments to both have = and == in REBOL?


There are times when you care about strict equality, and times when 
you don't. And it's a balancing act between usability, strictness, 
and risk; similar to the choice of making a language case sensitive 
or not.

It's tricky, too, because sometimes you'll want to add something 
that you think will make things easier, but it really causes more 
problems in the grand scheme of things. TO-STRING versus FORM is 
a good example. I would like to see REBOL minimize the number of 
things that differ only in very subtle ways (which are often not 
explicitly documented).

Let's look at this example. I have two words, iss and str, that represent 
some value, and they're some datatype. This is charasteristics of 
them:

>> series? iss
== true
>> series? str
== true
>> first iss
== #"a"
>> first str
== #"a"
>> length? iss
== 3
>> length? str
== 3
>> pick str 2
== #"b"
>> pick iss 2
== #"b"
>> str/3
== #"c"
>> iss/3
== #"c"

They seem quite alike. Are they equal?

>> str = iss
== false

Nope! Why not?

>> str
== "abc"
>> iss
== #abc


Again, I see little point in having both equal and strict-equal, 
when there's so little difference between them. If there were more 
differences between them, it would be good arguments to me for having 
both.

Issues and strings should be equal, I think, like integers and decimals 
can be equal, and numbers and chars can be equal.

Also I think, you can do exactly the same things with e.g. blocks 
and lists, but they're not equal:

>> [1 2 3] = make list! [1 2 3]
== false

(I totally agree, they shouldn't be strictly equal using ==.)

But if we didn't have strict-equal then how would we know when a 
variable is a pointer?

;consider:

>> a: "123"
== "123"
>> b: a
== "123"
>> b
== "123"
>> a
== "123"
>> append a "4"
== "1234"
>> b
== "1234"
>> a == b
== true

Obviously, a and b are pointers to the same memory address that  
holds the string.

You don't check, if they point to the same mem area with strict-equal, 
you use same? (or =?) for that:

>> a: "abc"
== "abc"
>> b: "abc"
== "abc"
>> a == b
== true
>> a =? b
== false


So it's not obvious, they point to same memory address, just because 
a == check returns true.

There are bugs in strict-equal? in R2 as well.

Can you give an example?

Ah right John, thanks.

Sorry, it is strict-not-equal? that has the bug:
>> strict-not-equal? 1 2
== false

STRICT-NOT-EQUAL? only checks types with integer! values. Use NOT 
STRICT-EQUAL? instead.

ok

Something funny. (We had a long discussion about this in R3-alpha.):

>> 0.3 - 0.2 - 0.1 = 0.0
== false

This is also false in e.g. the C language.

It's a floating point thing - 0.1 can't be represented exactly in 
IEE754 floats.

yes

>> $3.0 - $2.0 - $1.0
== $0

use money! datatype if you need precision

Those aren't IEEE754 :)

Or you could use fixnums: integer! and a scale.

In REBOL:
>> 0.1 + 0.1 + 0.1 = 0.3
== true


In C, this is not true. So REBOL tries to cope with this problem, 
but don't do it 100%.

In e.g. Python, my last test is also not true.

But Python is also a bit strange, it seems. From Python prompt:

>>> 0.1 + 0.1
0.20000000000000001
>>> 0.1 + 0.1 == 0.2
True
>>> 0.1 + 0.1 + 0.1
0.30000000000000004
>>> 0.1 + 0.1 + 0.1 == 0.3
False

Ah, maybe it's not so strange. C does the same.