Thanks, Did not understand this aspect of "paths".
Harold Grovesteen
GS Jones wrote:
> From: "Harold Grovesteen"
>
>> Can someone explain exactly what this code is doing? I'm confused by
>> this usage of ":" and its relationship to a block.
>> [EMAIL PROTECTED] wrote:
>>
>>
>>> Thanks Renaud,
>>>
>>> <Renaud>
>>> MultiplyBlocks: func [
>>> Block1 Block2
>>> /local sum
>>> ][
>>> sum: 0
>>> repeat i min length? Block1 length? Block2 [
>>> sum: sum + (Block1/:i * Block2/:i)
>>> ]
>>> return sum
>>> ]
>>> </Renaud>
>>
>
> Hi, Harold,
> Using the colon before a word retrieves its value. In the case where it is
> used as a part of a path, then the value serves as an index.
> A different example:
>
> a: [cat dog]
> :a ;returns the value of the word a, which is the block
> a/1 ;returns cat
> i: 1
> a/:i ;returns cat
>
> Hope this helps.
> --Scott Jones
>
>>> What was missing from my knowledge was how to reference a block using a
>>> variable (pardon my non-Rebol terminology) ..... When I'd tried things
>>
> like
>
>>> Block1/Ind I got told that was a bad path. Your little colon makes all
>>
> the
>
>>> difference.
>>>
>>> <Renaud>
>>> Note that you don't need to explicitly use RETURN in your functions,
>>
> since
>
>>> the last value of the affectation is still available when Rebol exits
>>
> the
>
>>> loop.
>>> </Renaud>
>>>
>>> True for MultiplyBlocks1. But MultiplyBlocks2 does need an explicit
>>
> return,
>
>>> at least on my machine. And, maybe it's a matter of style, but I'd
>>
> rather
>
>>> have an explicit return: it helps a stranger's eye when looking at code.
>>
> It
>
>>> also means I can add debugging code without breaking assumptions.
>>>
>>> <Renaud>
>>> It's also interesting to notice the relative speed of each
>>> function (multiply 2 blocks of 15 integers):
>>> <snip>
>>> </Renaud>
>>>
>>> I've changed my code to your "block/:i" format. It knocks 15% of the
>>> application run time. A worthwhile improvement indeed.
>>>
>>> <Brett>
>>> Next option would be to use Ladislav's %highfun.r script
>>> (http://www.rebol.org/advanced/index.html). There you will find
>>
> functions
>
>>> that will make this work more elegant, or a technique to make the
>>
> functions
>
>>> I've shown more generic.
>>> </Brett>
>>>
>>> Thanks for this reference. I certainly don't want to spend my life
>>> reinventing the wheel, and especially not clunky wheels
>>>
>>>
>>> <Michael>
>>> To write the most compact piece of code for performing this task one
>>
> could
>
>>> split some hairs and chop out a few chars here and there, but that does
>>
> not
>
>>> necessarily make it more readable/maintainable or better.
>>> </Michael>
>>>
>>> I wasn't trying to write the shortest possible code. But I like to think
>>
> that
>
>>> I write code that is easy to follow. Which is why the PICKs and FIRSTs
>>
> in my
>
>>> two samples niggled. They cluttered a function that ought to be simple.
>>
> Call
>
>>> it programmer's intuition, but I knew there must be a better way. But my
>>> RTFMing skills had failed to find it.
>>>
>>>
>>> Thanks for all the help guys. I think I am beginning to get the hang of
>>
> this
>
>>> language!
>>> Colin
>>
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubscribe" in the
subject, without the quotes.
