World: r3wp

Maybe 2 or 3 times slower.

sure, but i can change the other way. why start with a bad opcode 
and replace it with a bad, when i can have it the other way around?

Hey, Volker's got it! Use version 3, but call them add-i, sub-i, 
...

That's the REBOL style.

one of the "bad" should be good", but you understand what i mean.. 
;)

3b is better than 3, but still not necessary.

Part of what makes rebcode so fast is that it doesn't do path lookup 
for its operations. You would make it drastically slower if you changed 
it so it does.

DideC: Add a choice.
4) INTEGER add-i mul-i div-i ... / DECIMAL add-d mul-d div-d ...

there would not be much path-lookup, only on compilation. i dont 
know how rebcode works internally, i guess the words are not stored 
as rebol-words finally?

Using paths is not in the question (answer is no).

Internally, the opcodes are words that are bound to the system/internal/rebcodes 
context by the assembler. Then those bound words are used as an index 
internally to the implementation. No evaluation is involved at runtime.

That is according to Carl's writings so far.

DideC, I'd prefer the second or fourth (with -) choices.

REPLY TO URGENT NOTICE:  i propose i.add, i.mult, i.div etc... this 
way we include to rebcode a some object like stuctrure but only applayable 
on fonctions /operation names 

this allow us to not mistake betwin rebol/core  funtions and rebcode 
ones. As type take a  !  in rebol syntax we can use i!add i!mult 
i!div i!sub etc... I think this syntaxe would be really attractive 
for coders abit to object language. I.add or i!add is directly understable 
i -> interger add -> the operation applyed to integer! args ...

rebcode uses a full value for an opcode, 16 bytes? not something 
comprimized? if so, that works badly with cache-prefetch. But i agree 
the opcodes should have word-based names. so 2 if we think we stay 
with int/decimal, 1-2 others, 4 if we think we get special code for 
more types than the alphabet has letters.

shadwolf, please no ! in opcodes. That would be against the minimal 
use of the shift key that directs the syntax of hte rest of REBOL.

lol and i->add lol

in rebol function comes first, then arguments. no oops-syntax here.

too C like .... it's rebol  dude not python !!!

I prefer the opcodes first, before their typing.

<---- dude @_@

I prefer 1, as it is now. Keep it short. I think of the decimal variations 
like the normal ones, but with some extra (decimal has better precision 
and gives you decimals, so it's something extra than integer). It 
also take up more bits -> more bits, longer name. That's the way, 
I think. Also reminds me of C, where 10 is a short integer, and 10L 
is a long integer. (Not the same, but kind of the same thoughts.)

REBOL is not an object-oriented language shadwolf.

and addi minimizalkeystrokes too. :) and since Carl has choosen that 
way, but before he had addd etc, i opt for the smallest adjustion.

i clash with seti and such. then we should make everything integer, 
and have a setv for any-value.

hum and for decimal! value 1) gives addd
.... not clear enought i think

I never liked that integers were treated like a default value in 
C. This leads to its typing problems, excessive casting, character 
as integer, ...

About previous Alert (rebcode), and to filter noise, please vote 
in the "Opcode naming survey" checklist.

Add 2 to your prefer naming convention
Add 1 to your second choice

Thanks

Has choice 4 been added?

hum noise is for me ?

No.

vote cast.

was late. had to wait, everytime i wanted to vote the vote-list jumped.. 
:)

I don't like democracy, when my opinion is not choosen. ;-P

Well I am in Chicago, but I'll still vote only once :)

rebcode is like politics for me. I don't really care :-)

I do like it if your opinion is not choosen, as long as mine is! 
Have to look if i like democracy now. :)

as in the voting part

Something non-vote-related, would it be possible to have to-dec just 
assign the source to the destination when the source value is already 
a decimal? And the same for to-int, types adjusted?

then you cant convert in-place, as in your example. to-dec  a a

Right now to-dec sets the destination word to none if the source 
word refers to a decimal already.

And to-int works the equivalent way.

oops. misreaded just for only.

I agree then.

This is a place where I'd be willing to add a couple cycles just 
to prevent extremely obscure bugs.

By the way, I would prefer that randz and the trigonometric opcodes 
not be renamed unless you are planning to make versions of them for 
each type. They are already documented as being type-specific and 
there's only one of each, so it shouldn't be a problem.

Sorry, to-dec assigns 0.0 when the source is a decimal, not none. 
At least you can count on the dest being a decimal afterwards...

See what I mean by obscure bugs?

And to-int assigns 1 when the source is an integer. They're not even 
consistent with each other.