Multiple 'for each' in a repeat

[DarScott]

It might help to make code faster and easier to read to allow multiple 'for each' clauses in a repeat.

For example:

Code: Select all

repeat for each byte b in x for each item i in y

The syntax would need cleaning up and might be this:

Code: Select all

repeat for each char xChar in x and for each line yLine in y

I'm not meaning nested, that is straightforward as it is. I mean in parallel. That is, in the first example, the first byte and Item for the first iteration. Then the second byte with the second item for the second iteration. And so on.

The number of iterations can be for the shortest or for the longest, just as long as it is define.

This avoids having to maintain an index for the second iterator, clouding code and increasing execution time.

[DarScott]

This can be generalized to allow any 'repeat' specifications to be compounded. Like this:

Code: Select all

repeat 1000 times and for each character c in testDoc

The loop exits when the shortest one gets to its end.

Alternatives can be iterators or mapping operators.

The important use would be multiple 'for each' applied to chunks that are not accessed in constant time.

[Simon]

Hi Dar,
I think this is a great idea, but I'm nowhere near understanding if there could be a draw backs.

Simon

[RickA1]

I would like to see real examples of the use to better understand the proposed concept, like:

---Currently, you could write something like this:

###snippet1

---And using the proposed syntax you could write the same like:

###snippet2

------ Or vice-versa. New proposal first, and how it can be achieved with the current syntax after.
------ Then explain the gains of the new proposal if not obvious.

[DarScott]

Here is an example of new way and old way and a comparison.

Suppose I wanted to take the items of two lists the same size and then combine them in a new list with a tab in between.

Here is one way to do it now (untested):

Code: Select all

put 1 into index
put empty into newList  
repeat for each item i in list1
    put i & tab & ( item index of list2) & comma after newList
    add 1 to index
end repeat
if char -1 of newList is comma then delete char -1 of newList

Here would be the new way:

Code: Select all

put empty into newList 
repeat for each item i1 in list 1 and item i2 in list2
    put i1 & tab & i2 & comma after newList
end repeat
if char -1 of newList is comma then delete char -1 of newList 

The first method can be slow for long lists. That is, 'item index of list 2' takes a long time.

The second method is faster and is a little shorter. I think it is more readable, too.

[DarScott]

The repeat in the second example should be something like this:

Code: Select all

repeat for each item i1 in list1 and for each item i2 in lists

I forgot the second 'for each'.

[RickA1]

The not clear part of the new proposal is how it will handle multiple lists of different sizes, and the best approach to that.

What do you suggest? Go stepping while there is one larger list not finished yet and getting EMPTY for those items on shorter lists already done?

And as you propose a not sequential approach, I believe that the syntax FOR EACH I1 AND FOR EACH i2 could transmit the sequential idea of get i1 and loops i2, then get next i1.

As for a parallel approach, maybe removing the internal FOR should be better, like:

Repeat for each item i1 in list1 and each item i2 in list2

REPEAT FOR EACH ..... AND EACH .... AND EACH ...

[DarScott]

I think the single 'for' and multiple 'each' is clearer. Good idea!

It might not lend itself to multiple repeat specifiers in general, but those might not be important. This applies to 'repeat for'. That is fine.

I think 'and each' should be unambiguously parseable. (The word 'and' is an operator in LiveCode so we have to watch that we don't accidentally create something that might be parsed two ways.)

[DarScott]

Maybe there is a way to get much of the performance aspect of this without a language change.

The enhancement would be this: Somehow hidden inside the engine is an optimization for dealing with a chunk near any of these locations:
1. Near the front
2. Near the end
3. Near the last chunk access

Some other cool optimization might also address the performance aspect of this feature request.

[RickA1]

I think 'and each' should be unambiguously parseable.

Contexts solves this situations. When the parser finds a "REPEAT FOR EACH" is starts a new context focused to solve this special kind of syntax. In this context "AND EACH" makes sense as an "END OF LIST TO BE ADDED AND START OF a NEW ONE" (both words together, not just a boolean AND (error)). AND EACH points a "here comes one more context to solve into some other value/list to join the parallel loop of lists".

[RickA1]

Somehow hidden inside the engine is an optimization for dealing with a chunk near any of these locations:
1. Near the front
2. Near the end
3. Near the last chunk access

Didn't understand what you mean here.

[DarScott]

I was thinking that my example using the index variable would run fast under some internal optimization conditions. One possible optimization is fast access to chunks in the middle of large strings.

I'm assuming that 'item 320 of megaByteString' would be slow. It has to be counted from the front to be found.

But, what if I just referenced 'item 319 of megaByteString'? Maybe LiveCode could remember that location and find item 320 quickly.

[DarScott]

Today I read about the occasional internal association of a number or a byte-string form with a string. Though it is not exactly an alternative representation of the string, maybe the last chunk referenced can be associated with the string, all hidden inside for optimization.