World: r3wp

The dots were one of my favorite choices.

OK I know it's a dialect, not REBOL, but there is not a single word 
in REBOL that uses dot. Decimals and tupples use them, but not words.

You can use dots in words.

Most don't.

I can live with dots but I don't like it, looks really un-REBOLish

Quick to type though, at least compared to - on my keyboard.

So, why hasn't the syntax signiature of brab changed to match the 
new behavior? In theory, we can now specify a literal integer at 
the first position, as that is what the label fixup changes brab 
to in the special case. The syntax check doesn't allow it though, 
because it still looks for word! or block! only.

; BRAB should be like this
brab: ["Branch block table" block! | word! | integer! word!]

Hm this is not directly related to ".",  but now I realize I've got 
some 1000 lines of rebcode to rewrite :)

Search and replace :)

:)

Brian - it was not about "qick to type" ;-) If so, we should replace 
path char with dots too ...

I agree with Kru that once again probably the poll was only informative 
and the voice of most - ignored ...

Well, the dot and dash versions were really arbitrary between them. 
We couldn't do paths and the no-change and no-seperator choices had 
significant negatives.

At least the dot being unlikely in normal rebol code makes these 
opcodes more useful in rewrite rules, since you will know what to 
not look for.

I suggested the dash, but the dot is just as good to me.

And anyway, REBOL syntax is designed to be quick to type. That is 
why we use - instead of _ and [ ] instead of { } like other languages.

but why not -

As Cyphre said: because dot looks more like assembler ;)

never mind, I will probably never write rebcode leve code anyway 
:-)

It is a good visual reminder of the different semantic model, this 
is true...

Well, I don't write View code. We all have our strengths :)

And on that note, where's the Core version of the new build?

Testing: The new brab works. The eq.i opcode still works on logic 
and datatype values as well.

For those with a lot of rebcode already, there will probably be a 
conversion tool to update your scripts available shortly.

I can live with dots but I don't like it, looks really un-REBOLish

 -- That's by design. The opcode names are not human friendly either; 
 also by design. The idea being that rebcode is *not* REBOL, and having 
 it look more like ASM makes you more aware of that. There will probably 
 also be a separate style guide for rebcode at some point.

Kru: we have a script that does the conversion automatically. Ask 
Ladislav.

(ah, i see Gregg told you already ;)

Gabriele: thanks but I've already rewrote most of my code yesterday. 
I don't know your conversion script but I've had different scripts 
using 1.30.50, .51, .52 and even old 1.4 alphas so does your script 
cover all different syntaxes or just the latest one?

only   mul -> mul.i, muld -> mul.d and so on. i.e. latest.

And rewriting scripts manually was great opportunity to otimize them 
to (and sometimes by factor of two, so it was for good :))

:-)

otimize-optimize

What's the problem with dot? I was not voting, but must say I like 
dot. At least it looks differently from variable names, where I use 
- and _ chars.

guys, rgba to integer conversion link is dead ...

should I rambo-it? :-)

this looks like a bug to me:

>> o1: context [a: 0 rc: rebcode [x][set a x]]
>> o1/rc 3
>> ? o1
O1 is an object of value:
   a               integer!  3
   rc              rebcode!  [x]

>> o2: make o1 []
>> o2/rc 5
>> ? o2
O2 is an object of value:
   a               integer!  3
   rc              rebcode!  [x]

>> ? o1
O1 is an object of value:
   a               integer!  5
   rc              rebcode!  [x]

seems rebcodes are not rebound.

should I RAMBO it?

I think yes. needs either docu or fix.

maybe thats one of the reasons why all branches are relative? to 
easier copy on make?

submited

Thanks Petr! No need to RAMBO it. I'll look into it.

questions we need to get an answer for, especially from BrianH as 
a supplier of #3947:

Related to string COMPARE are these features:
1) case sensitive or not
2) which string is "greater"
3) index of non-equal (tail of compare)
4) find

Well after testing, it seems that the behavior of cmp is:

1) Case sensitive. Lowercase the strings for case insensitive compares.

2) If the first string is less than the second, cmp sets the return 
word to -1, equal sets to 0, and greater sets to 1. If two strings 
of different lengths and are the same for the length of the shorter 
string, the longer string counts as greater. Otherwise, the numeric 
equivalent of each corresponding character is compared.

3) You can roll your own with length?, repeatz, pick, lt.i, gt.i 
and breakt (if you want, I'll do it). The cmp opcode won't help here.
4) Use apply i find [ser val] - it'll be faster.

Still, I'm glad to see cmp, sign and asr, and the fixes are welcome 
too. I didn't know that lsr was not unsigned before - that's what 
lsr means. Good fix!

; Index of non-equal, 1-based, assumes indexes within bounds
length? x a
length? y b
gt.i x y
ift [set.i x y]
repeat i x [
    pick x a i
    pick y b i
    eq.i x y
    breakf
]
; i = first non-equal index

It would probably be better to do case-sensitive compares anyway, 
as it would allow you to compare binaries. Character case needs code 
pages and such to work anyway when you have Unicode, or languages 
other than English.