Flesxible looping [Was: Making Revolution faster with reallybig arrays]

[Dennis Brown]

Alex,

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?

Dennis



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 
>> Revolution.
>
>
> Dennis,
>
> 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".