World: r3wp

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]

>> a: 1

== 1

>> type? a

== integer!

>> type? 'a
== word!

>> b: [a
]
== [a
]
>> type? first b

== word!

>> print a

1

>> print first b

a

>> print 'a

a

Help says print does an evaluate (presumably a reduce) if the value 
to print is a block....So it is documented behavior:
  http://www.rebol.com/docs/words/wprint.html

ok, thanks ....

Hi!
Does Rebol suport AUTH=NTLM in IMAP protocol?
Thanks in advance!

I think not. In the past, Doc did some tests, but not sure ...

http://softinnov.org/rebol/ntlm.shtml

Thanks Pekr - I already saw it, but I am thinking how to use them 
in case of IMAP.

Is it just like opening port?

Don't know - never worked with it ...

trouble with double caret afer forming a string from block.

print y: form [KBE RKH CSCD IDJ MNOV LCAPB CWCO ^DJA]
KBE RKH CSCD IDJ MNOV LCAPB CWCO ^^DJA

how can I avoid the double caret?

form, mold or composing the string via foreach etc. doesn't work 
here.