[REBOL] Re: Shortcut word available?
From: moliad::gmail::com at: 15-Jun-2007 22:23
here are a few distinct reasons I can sum from the top of my head:
1. much easier to handle words within blocks.
Reducing draw and vid blocks is a pain, since you have to make every word a
lit-word, and then some word types get evaluated and are not returned
>> reduce ['ree:]
hum.. that's not what I want... so I'd need to add a 'TO-SET-WORD in there
>> reduce [ to-set-word 'ree]
on large blocks this becomes just unwieldy. its even worse when generating
the word blocks dynamically
2. I use the /deep refinement often, its an order of magnitude simpler than
trying to nested reduce your way into deep blocks.
reduce [reduce [reduce [myval]]]
ok, in this example the byte count is the same, but think of a real block
and what kind of monster the reduce version turns into.
3. very powerfull pre context setup:
since contexts bind their values before reducing them, this is not possible:
myctx: context [
again, its possible using reduce... but have fun trying to do that with a
real object which has funcs objects and all !
so this becomes much easier:
myctx: context compose [
again, the /deep refinement here is a god send.
gui: [button [print (myval)]]
prop: context compose [
gui: (compose/deep gui)
this is especially true when things are decoupled and setups are not part of
your code. try to explain to an admin why and how he should put reduce and
various 'TO-xxx words everywhere, when you can just say... "here, put a ()
around the values, here are the options you can use ..."
4. compose gives you the freedom of NOT including a surrounding  , this is
something reduce can only do using things like either and not returning a
value in the false. again, much more complex.
a: [1 2 3]
== [1 2 3]
== [ 1 ]
== [[1 2 3]]
== [ 1 ]
5. in most of my applications, absolute speed is secondary to maintenance,
and dev time. REBOL is fast enough so that in 95% of stuff I don't even
have to think about "speed" if I press a button and the result appears
before I can blink the eye... I'll admit that the 0.0002 second difference
doesn't quite hit me as such an issue ;-)
in tight loops, obviously, I'll eventually start working on optimisation,
but that's usually not as necessary as people think ... just changing the
windows size of any view app will give you more speed difference than most
series optimisation tricks you can think of.
Now this all being said, I still use reduce a lot too. just in other
areas... in fact, I'm probably one of the people who run-time generates the
most code in my applications. I love REBOL's ability to self modify and
run-time bind values... so that might be why you see more composes (and
reduces) than the norm in my code... I just find its a logical way of
On 6/15/07, Peter Wood <pwawood-gmail.com> wrote: