Flesxible looping [Was: Making Revolution faster with reallybig arrays]
see3d at writeme.com
Fri Apr 15 07:58:38 CDT 2005
Sometimes I feel like I have been really stupid when the light dawns.
Of course there is a way to specify a sequential access in a single
statement. The catch is that an extra variable needs to be specified
and modified. Something like this:
put line offset tCharOffset of string into container --tCharOffset is
advanced to after return
Or as a function:
get sequentialLine((tCharOffset),string) --still advances tCharOffset
This would take care of fast sequential access to strings.
What do you think?
Is there a better form that this could be put into for Transcript?
On Apr 13, 2005, at 11:25 AM, Alex Tweedly wrote:
> Dennis Brown wrote:
>> The Idea is to break apart the essential functional elements of the
>> repeat for each control to allow more flexibility. This sample has a
>> bit more refinement than what I posted yesterday in Bugzilla.
>> The new keyword would be "access" , but could be something else.
>> An example of the use of the new keywords syntax would be:
>> access each line X in arrayX--initial setup of pointers and X value
>> access each item Y in arrayY --initial setup of pointers and Y value
>> repeat for number of lines of arrayX times --same as a repeat for each
>> put X & comma & Y & return after ArrayXY --merged array
>> next line X --puts the next line value in X
>> next item Y --if arrayY has fewer elements than arrayX, then empty
>> is supplied, could also put "End of String" in the result
>> end repeat
>> Another advantage of this syntax is that it provides for more
>> flexibility in structure of loops. You could repeat forever, then
>> exit repeat when you run out of values (based on getting an empty
>> back). The possibilities for high speed sequential access data
>> processing are much expanded which opens up more possibilities for
> I think having more flexible repeat structures to allow parallel
> passes through lists or arrays is a really good idea, but I don't like
> the form you have suggested. It seems wrong to have separate
> statements to setup the loop; as far as I know, the language currently
> keeps the meaning of each statement self-contained, so I think this
> multi-line form would be a hard one to "sell".
More information about the use-livecode