World: r3wp

jython? So python version emulated in JAVA is faster than native 
REBOL? :-)

Davide, try an R3 version too.

java is in the class of c++ in performance AFAIK

I remember the in 1998 there was a mame - java applet that could 
run phoenix at 100% of the velocity with no skipframe (I had a pentium 
100 Mhz at that time)

using _prev and _next instead of function the result is:
Time per iteration = 0:00:00.00056687

with R3:
Time per iteration = 0:00:00.00034359

I don't think, Java is as C++ in performace. C++ can be compared 
to C in performace, and Java is at least 8 times slower. See e.g.:
http://www.timestretch.com/FractalBenchmark.html

R3 performance: Interesting. :-)

Yes, I meant in the same class if compared to ruby, python or similar.

java is slower than c++ (but I think that 8x slower is not realistic 
in common usage)

David you can dump those mezzanines and just use make function! instead 
of 'does and 'func.  Maybe use the operators such as <> instead of 
not equal? and use chain assignment here and there were applicable.

a bit OT: yesterday I've discovered that compiled VB6 run as fast 
as tcc in number crunching :-)

http://tinyurl.com/5nezt9,already dead ?

works here, the plain url is http://blog.dhananjaynene.com/2008/07/performance-comparison-c-java-python-ruby-jython-jruby-groovy/

Java is faster than REBOL at Java-style code, because REBOL is optimized 
for a different code style. If you are writing code in REBOL style 
then it can be faster than Java in some cases, or at least less slower 
in other cases. In this case what is slowing down REBOL is all of 
the unnecessary accessor code: OO overhead that Java can optimize 
away, but it REBOL you just don't write in the first place.

On the other hand, you probably ran your tests on different hardware 
than he did, so time results may not be comparable :)

I know that rebol appeared to be the slowest language on debian language 
shootout , but then cheyenne is *much* faster webserver than any 
of the ones made in dynamic languages I tried (even lua). so speed 
is a relative thing it seems (like Brian says)

also when using dialects, there is often a huge speed gain, but you 
can't really code like that in most other languages.

In this case, I think that  we can be happy with performance too.

Is there a way to pass a refinement further? so I don't have to do 
something like
do-some: func [ /ref ] [ either ref [ do-more/ref ] [ do-more ] ]

that is an oldie. In R3 as well as in R2+Rebcode you can use a native 
APPLY

otherwise you are mostly "out of luck"

aha, my r2 doesn't seem to have apply.. I will solve it some other 
way :) thanks

Well, the mezz. Apply may be quite slow, but if it suffices...

Then you can download it somewhere

I will use normal argument .. I don't want to further complicate 
codebase to make it a little nicer

http://www.rebol.org/view-script.r?script=apply.r

There's an APPLY in R2/Forward that replicates R3's APPLY native. 
Either the native or the R2/Forward version will be in 2.7.8.

janko, when I have chained calls which use options, I do this:

func [/opta /optb /options oblk][ 
	oblk: any [oblk copy [ ] ]
	if opta [append oblk 'opta]
	if optb [append oblk 'optb]

	; then use the block exclusively using find.
	if find oblk 'opta [print "option A supplied"
	if find oblk 'optb [print "option B supplied"

	; this way you can easily chain options 
	do-something/options oblk
]

oops... missing end "]" chars ... you know where.

I've done the same thing as Max, and if there is just one refinement, 
I'll still use EITHER. If you have a scenario where there's an entry 
point that delegates work and requires multiple options, consider 
making it a dialected func.

The APPLY mezzanine in 2.7.7 has a minor, obscure bug that is fixed 
in a later R2/Forward release, and later R2 mezzanine source. But 
aside from that it works fine, and I have used it in production code 
with no errors (the bug was so obscure that it never came up in practice 
or testing).

Maxim, you forgot to copy oblk.

Without APPLY or something like it, you end up having to do some 
tricky stuff sometimes. See this REMOLD backport for instance:

remold: func [
	"Reduces and converts a value to a REBOL-readable string."
	value [any-type!] "The value to reduce and mold"
	/only "For a block value, mold only its contents, no outer []"
	/all "Mold in serialized format"
	/flat "No indentation"
][ ; Nasty, but the best you can do without native APPLY
	do pick pick pick [[[
		[mold reduce :value]
		[mold/flat reduce :value]
	] [
		[mold/all reduce :value]
		[mold/all/flat reduce :value]
	]] [[
		[mold/only reduce :value]
		[mold/only/flat reduce :value]
	] [
		[mold/only/all reduce :value]
		[mold/only/all/flat reduce :value]
	]]] not only not all not flat
]
; Note: Uses APPLY in R3.

good catch on the copy

And that REMOLD should be using get/any 'value instead of :value 
- an R3-ism that crept into the code.

is get/any 'value faster?

No, but it supports molding unset! values and errors.

ok, thought that was the reason

In R3 :value supports that - it means GET/any instead of GET.

cool! its easy to trip R2 when scanning blocks and an unset! value 
lies there

We did a *lot* to make R3 easier and more powerful :)

Nevermind, I think the [any-type!] in R3's REMOLD is the error, not 
the :value in the backport. I'll fix it now and put in a ticket.

See my beloved version :)

remoldx: func [x /all /flat /only][
	do head clear change change change next 'mold/?
		pick [[] all] not all
		pick [[] flat] not flat
		pick [[] only] not only
		reduce x
]

You forgot to copy 'mold/? :)

no, it doesn't matter
because of the clear

The clear clears the end, since that is what CHANGE returns, so it 
has no effect.

it has an efffect because the path is modified inside the source 
after each call

but i have not tested without clear

Yes, but at the position the CLEAR is in the source, it has no effect. 
The modifications to the path persist.

>> source remoldx
remoldx: make function! [[x /all /flat /only][
    do head clear change change change next 'mold/?
    pick [[] all] not all
    pick [[] flat] not flat
    pick [[] only] not only
    reduce x
]]
>> remoldx/all/flat/only [1 2 3]
== [1 2 3]

>> source remoldx
remoldx: make function! [[x /all /flat /only][
    do head clear change change change next 'mold/all/flat/only
    pick [[] all] not all
    pick [[] flat] not flat
    pick [[] only] not only
    reduce x
]]

i tried without 'clear just now, and as I thought, it's broken right 
now