World: r3wp

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.

anyone remember where the parse demos showed a calculator dialect 
?

just need simple arithmetic

This? http://www.rebol.com/docs/core23/rebolcore-15.html#section-6

yes .. thanks

saves me a few mins writing my own !

I was trying to help new guy on ML, and just would like to ask - 
why is there a difference in evaluation when printing a block, and 
printing first block?

>> colors: [red green blue]
== [red green blue]
>> print colors
255.0.0 0.255.0 0.0.255
>> print first colors
red

so 'first does not reduce the value, while print itself does?

it doesn't come from print behavior
but, it's how reduce works
reduce first [red]