Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

[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 correctly ex:
>> reduce ['ree:]
== [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]
== [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]]] vs. compose/only/deep [[[(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: myval: 666 myctx: context [ myval: myval ] 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: myval: 666 myctx: context compose [ myval: (myval) ] again, the /deep refinement here is a god send. myval: 666 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] b: 1 compose [(a)] == [1 2 3] compose [(b)] == [ 1 ] reduce [a] == [[1 2 3]] reduce [b] == [ 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 reboling. -MAx On 6/15/07, Peter Wood <pwawood-gmail.com> wrote: