Flexible looping [Was: Making Revolution faster with really big arrays]

[Dennis Brown]

Alex,

I see your point and that was my first thought also.  After sleeping on 
it, what I am really suggesting now is not "breaking apart" the repeat 
structure as much creating an new sequential access method operator(s). 
  This is more flexible than tying it to the loop operator.  It means 
that you have complete control over the separate items and can make 
them out of sync on purpose (it might even be nice to be able to 
specify a starting point instead of creating a new chunk --kind of like 
the skip n lines in a search.  For instance, you want to match every 
line in A with every other item in B.  It just happens to be a quirk 
that the pointers are currently embedded into the repeat for each 
structure.  This would also significantly simplify the possible syntax 
variations in the repeat structure.

The access each line X and the next access X would be paired.  Help me 
out.  How can this be specified so that it makes sense for the 
language?  It would have interleave the block structure to be useful.

Access each line X in arrayX from line 3 --just creates the pointers 
and access mode structures
   do something
next access X --grabs X and advances the line pointer
end access X --destroys the pointer structure?

I would also like it applied to Arrays if the order they come out is 
deterministic --like the order they were created, or numeric order of a 
numeric key.

And yes, I am all for making the language more readable --self 
documenting.  After all that is one of the points of X-Talk.

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".
>
> I think it would be better to add a new keyword to indicate parallel 
> looping; the primary loop determines the repeat-termination test 
> criterion, while the others are incremented/advanced in synch. (of 
> course, using exit allows you to terminate the loop based on the 
> secondary loops if needed).
>
> I'd suggest the word "also" since it's not currently used, or perhaps 
> the phrase  "also each".
>
> So the form would be something like
>
>> repeat for each line X in xList also item Y in yLine  repeat for each 
>> line X in xList also each item Y in yLine  repeat for each line X in 
>> xList and also each item Y in yLine
>
> and of course there could be more than 2 :
>
>> repeat for each line Y in ylist also line x in xlist also item z in 
>> zlist also item name in        namelist ...
>
>
> This would allow the variants
>
>> repeat forever also each item Z in theList
>> repeat for each element E in myArray also each line X in xList
>> repeat with i = 1 to 100 also each line X in xList
>
> etc.
>
>
> And for symmetry, it might also be feasible to allow
>
>> repeat for each X in Xlist also i = 1 step 1
>
> (since there's not a terminating condition in the secondary, it would 
> confusing to have i = 1 to 100, so simply specify initial and step 
> values).
>
>
> Similar to this, I'd love to see a method for accessing arrays which 
> gives both the key and the element. Currently, you can say
>   repeat for each line K in the keys of myArray
>     put myArray[k] into V
> but most modern languages have something like
>   for (k,v in myarray)
> which gives both key and value without needing to do another hash 
> lookup.
>
> And now that I'm started on this topic, I've always envied the 
> readability of Python's tuple-assignment. I find
>   x1,y2,x2,y2 = myRectangle
> much more obvious than
> x1 = myRectangle[0]
> y1 = myRectangle[1]
> x2 = myRectangle[2]
> etc.
>
> In Transcript, I really wish I could say
>   put myRectangle as items into x1,y1,x2,y2
> or
>   put the items of myRectangle into x1,y1,x2,y2
> instead of the clumsy
>  put item 1 of myRect into X
>  put item 2 of myRect into Y
> etc.
>
> No performance advantage - but so much more readable.
>
> -- 
> Alex Tweedly       http://www.tweedly.net
>
>
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.308 / Virus Database: 266.9.7 - Release Date: 12/04/2005
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/use-revolution