World: r3wp

So it is 4 parts to a string.

>> license
...
The copyright, trademark, and other proprietary rights notices
contained in the SOFTWARE may not be removed, altered, or added
to in any way. You may not reverse engineer, decompile, or
disassemble the SOFTWARE.
...

...

Seems that some here broke the REBOL EULA.

I would think we are guessing if anything Doc.

educationnal purpose

Oh you must be referring to those that dissassembled.  Shame on you 
Steeve and Brian.  ;-)

i'm under Europe laws here

was funny when Ladislav explained his mem manipulation things to 
Carl.  ;-)

Carl was impressed more than anything hehehe

There's no such exception in the EULA. The EULA is a contract between 
the end user and the publisher. AFAIK, EULA applies in EU too.

Much of my comments are just guessing, mister cop  :-)

Doc have you ever disassembled REBOL?

I don't want to defend RT here, just reminding some of you that using 
REBOL implies agreeing the EULA. Not that I fully agree with RT ways 
of distributing REBOL, but this is an official REBOL channel that's 
[web-public], so at least we should respect the EULA.

Paul : never and I never plan to do so.

Excellent Doc!

Good point also about it being web-public.

As you state above, guessing how some parts of REBOL work internally 
can be done without breaking the EULA.

Doc, knowing how rebol works internally isn't guess work and disassembling.

some of this comes from RT itself, and even from such things as playing 
around with structs.

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