World: r3wp

move-next 'series
 looks ok but multiply looks weird.
but ++ already works for series as you say.

++ : "Increment an integer or series index."

Has anyone said the following before?

call-by-word

I didn't hear that before.

I suggest: skip ++ and use NEXT with call-by-word to do the same. 
Less functions to remember that way.

using NEXT with call-by-word (I like the name :) ) looks ok to me, 
but I remember that, "guru"s may say "it leads performance overhead 
for next, as it is a native and used a lot. it should check the argument 
and get-value if it is a word."

I'm not too sure about additional overhead, depending on how NEXT 
is implemented today. My guess is, NEXT already test for different 
datatypes, as it can handle blocks, strings, etc. To in that SWITCH 
(guessiong) in the source code, it just have to include the word! 
type also and handle that, and default: give the error.

To -> So

and *guessing* :) Getting late = more typing errors.

Then we could have things like:

>> a: 41
>> next a
== 42
>> a
== 41
>> next 'a
== 42
>> a
== 42

NEXT already test for different datatypes, as it can handle blocks, 
strings, etc.

But it's all series type. So no type checking I think. It supports 
only series and port values.

If it supports those actions, then it should be everywhere:

SKIP, ADD, DIV, NEXT, NEGATIVE, AND etc.. then it leads a overhead.

I would guess, the code is different for doing next string, next 
block and next port.

I like the idea, but it looks it needs using too much GET value in 
all the actions above.

Yeah, and some may argue, it's less readable with call-by-word options. 
But some probably also finds it strange, that NEXT string doesn't 
alter the string, while LOWERCASE string does.

A lot of things like

var: var + something	; or
var: add var something

could be changed to

add 'var something

It's kinda like the += in C.

'var + something
hmm... that's not too readable.

infix functions, op!s should not support this, because it is really 
not readable

Yeah, I tend to agree.

what about writing a bunch of new functions suffixed with '
ADD'
NEXT'

Yes, REBOL makes it possible to do all this already. In fact, all 
the natives could be recreated as mezzanines supporting call-by-name, 
but that'll be slow of course.

You can easily see the extra overhead:
SOURCE ++
additional IF, GET, SET and CASEs..

this should be in all the natives. look too much overhead I think.
Let's wait for comments from gurus.

I'm leaving now. Bye.

ciao

There is a huge speed difference: (my benchmark function executes 
given block 1'000'000 times)
>> i: 0 benchmark [i: i + 1]
== 0:00:00.25
>> i: 0 benchmark [++ i]
== 0:00:02.578

That's more the difference between a native and a mezzanine, than 
the method.

Related is using POKE on e.g. time!:

>> t: 10:20:30
== 10:20:30
>> poke t 2 42
== 10:42:30
>> t
== 10:20:30

But we can change a time using a set-path!:

>> t/2: 42
== 42
>> t
== 10:42:30

So the set-path! way doesn't do the same as POKE in this case.

That was in R2. In R3, POKE can't handle time!

And that's probably an ok decision.

That's more the difference between a native and a mezzanine, than 
the method.
 - That's right.

From R3, where ++ is native::

>> dt [loop 10000000 [i: i + 1]]
== 0:00:01.90374
>> dt [loop 10000000 [++ i]]
== 0:00:01.011743

Try it in R3:
>> dt [i: 0 loop 1000 [i: i + 1]]
== 0:00:00.000251
>> dt [i: 0 loop 1000 [++ i]]
== 0:00:00.000383


Then the difference is more due to the code in ++ to tell whether 
i is an integer or a series

Hm, try do more loops on your system, Brian.

Weirdly enough, I think that it might be faster sometimes depending 
on what is going on in the background.

Nope, consistently faster. No interpreter overhead.

>> dt [i: 0 loop 100000 [i: i + 1]]
== 0:00:00.041421
>> dt [i: 0 loop 100000 [++ i]]
== 0:00:00.022857
>> dt [i: 0 loop 1000000 [i: i + 1]]
== 0:00:00.205488
>> dt [i: 0 loop 1000000 [++ i]]
== 0:00:00.130813

Yes, ++ is faster, contrary to your first test.

And it makes sense.

The ++ and -- functions are in R2 for convenience and compatibility, 
not for speed.

++ is native in R3

yes and yes

Still, I made them as fast as I could while still being compatible.

So we would expect things like

	next 'series

to be faster aswell than

	series: next series

But not as useful. The current NEXT can operate on values returned 
from functions, or series referred to by protected variables.

My suggested NEXT can do that also. I just suggest adding the possibility 
to call those with call-by-word.

NEXT cannot do it

It does not have that kind of argument evaluation

You would need to change the argument evaluation standard for it