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:g:mail 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:gmai:l 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