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

Shortcut word available?

 [1/15] from: robert:muench:robertmuench at: 8-Jun-2007 15:22


Hi, IIRC there is a way (word) to avoid code like this: either my-word [my-word][none] But I can't remember it... anyone? Robert

 [2/15] from: GedB:Rushcoding at: 8-Jun-2007 14:51


On 6/8/07, Robert M. M=FCnch <robert.muench-robertmuench.de> wrote:
> Hi, IIRC there is a way (word) to avoid code like this: > > either my-word [my-word][none] > > But I can't remember it... anyone? Robert
attempt [my-word]

 [3/15] from: chris-ross::gill::com at: 8-Jun-2007 10:01


any [my-word] or all [my-word] On Jun 8, 2007, at 8:22 AM, Robert M. M=FCnch wrote:

 [4/15] from: moliad:gm:ail at: 8-Jun-2007 12:24


hi guys, when using 'ANY or 'ALL, just remember that if 'MY-WORD is worth false on entry, then you will receive none instead... just so you know. the attempt solution also works if my-word is unset, which is sometimes a boon, but it might be slower... -MAx On 6/8/07, Christopher Ross-Gill <chris-ross-gill.com> wrote:

 [5/15] from: tim-johnsons::web::com at: 8-Jun-2007 8:30


On Friday 08 June 2007, Christopher Ross-Gill wrote:
> any [my-word] > > or > > all [my-word]
;; If 'my-word has no value, you get this:
>> any[my-word]
** Script Error: my-word has no value ** Near: any [my-word]
>> all[my-word]
** Script Error: my-word has no value ** Near: all [my-word]
>> attempt[my-word]
== none ;; 'attempt will assure that the code continues Tim

 [6/15] from: chris-ross::gill::com at: 8-Jun-2007 22:09


Ah, but he was only asking for a shortcut for 'either, in which case 'any and 'all would be faster. And even if 'my-word is false (Max), 'any and 'all would work the same way as Robert's 'either.
>> either my-word [my-word][none]
** Script Error: my-word has no value ** Near: either my-word [my-word] [none]
>> any [my-word]
** Script Error: my-word has no value ** Near: any [my-word]
>> all [my-word]
** Script Error: my-word has no value ** Near: all [my-word]
>> my-word: false
== false
>> either my-word [my-word][none]
== none
>> any [my-word]
== none
>> all [my-word]
== none On Jun 8, 2007, at 11:30 AM, Tim Johnson wrote:

 [7/15] from: moliad:g:mail at: 10-Jun-2007 2:33


hi chris , I was just identifying the differences between the two main ideas... cause for some novices these details are not obvious. Somehow, when I reply on the ML I try to speak to the 'wider audience' which is a difference than when using chat. (altme) thanks for spitting them out explicitely and dumping here. -MAx On 6/8/07, Christopher Ross-Gill <chris-ross-gill.com> wrote:

 [8/15] from: anton::wilddsl::net::au at: 12-Jun-2007 18:57


Is that for passing through arguments when wrapping a function ? The best way I found for that was to write my own mezzanine. Anton.

 [9/15] from: robert::muench::robertmuench::de at: 15-Jun-2007 9:38


On Tue, 12 Jun 2007 10:57:53 +0200, Anton Rolls <anton-wilddsl.net.au> wrote:
> Is that for passing through arguments when wrapping a > function ? > > The best way I found for that was to write my own > mezzanine.
Hi, no. It's just a pattern that I often find in my code. Hence I thought others have the same situation, and maybe Rebol has a special word for this (like the UNLESS shortcut). Robert

 [10/15] from: moliad::gmail::com at: 15-Jun-2007 11:34


I also use the compose trick often to "blockify": val: compose [(val)] (just including this in the thread, cause its related, and usefull for searching purposes) -MAx On 6/15/07, Robert M. Münch <robert.muench-robertmuench.de> wrote:

 [11/15] from: pwawood::gmail::com at: 16-Jun-2007 8:03


MAx I've noticed that you use compose quite a lot in your code. When you don't need selective evaluation, what is the advantage of 'compose over=20 'reduce? it seems to be slower.
>> b: "MAx"
== "MAx"
>> speedtest: [
[ st: now/time/precise [ loop 10000 [compose [(b)]] [ print now/time/precise - st [ st: now/time/precise [ loop 10000 [reduce [b]] [ print now/time/precise - st [ ]
>> do speedtest
0:00:00.138865 0:00:00.082445 Regards Peter On Friday, June 15, 2007, at 11:34 pm, Maxim Olivier-Adlhoch wrote:

 [12/15] 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:

 [13/15] from: pwawood::gmail::com at: 16-Jun-2007 15:20


MAx Thanks for the detailed, helpful and instructive explanation. You make a strong case for compose. Regards Peter On Saturday, June 16, 2007, at 10:23 am, Maxim Olivier-Adlhoch wrote:

 [14/15] from: robert:muench:robertmuench at: 17-Jun-2007 15:09


On Sat, 16 Jun 2007 09:20:16 +0200, Peter Wood <pwawood-gmail.com> wrote:
> Thanks for the detailed, helpful and instructive explanation. You make > a strong case for compose.
There is one situation where I don't like COMPOSE (because it's not easy to handle) and that's when you need to do some calculations with parens inside a block. In this case COMPOSE interprets the parens differently. Robert

 [15/15] from: moliad::gmail::com at: 17-Jun-2007 9:56


On 6/17/07, Robert M. Münch <robert.muench-robertmuench.de> wrote:
> > There is one situation where I don't like COMPOSE (because it's not easy > to handle) and that's when you need to do some calculations with parens > inside a block. In this case COMPOSE interprets the parens differently. > Robert >
very true, when there are already parens in a block, its not very practical to use compose. In most cases, surrounding the math with an extra all-encompassing set of parens work. if you really want the original parens to be part of the block, although clumsy, you can just include them within a block. The compose will remove the block and leave the content intact (unreduced). ex:
>> a: 3
== 3
>> compose [([(a)])]
== [(a)]
>> compose compose [([(a)])]
== [3] now, I didnt't say the above in a hope of "defending" compose ;-). but the above can help if you've got just a few parens in a large setup... -MAx