Repeat syntax addition

[Ben Rubinstein]

(Going back to HyperCard?) the concepts used to be containers and "sources of 
value" - where the latter can be a literal, a function call, an expression...

I always thought that containers were a subset of sources of value, defined as 
the items where you could set the value as well as get it; but looking at the 
current LiveCode user guide I see that these are used as exclusive sets, where 
the key distinction is not whether the item can be both evaluated and changed, 
but whether it can be changed using "put".  So a field is a container, just as 
a variable is; but a property is a "source of value" because you need to use 
the "set" syntax to change it, so it's grouped with a constant literal or an 
expression, which is read-only.  This seems wrong to me, and I don't know 
whether it marks a subtle change.

At any rate, the desirable change in the dictionary would be to replace 
"container" with "container or source of value" - better not to introduce a 
new term altogether!

Ben

On 06/04/2015 04:21, Mike Bonner wrote:
> Use of the word "Container" is a bit deceptive.  Perhaps "datasource" would
> be better.  Is it still possible to add notes to the dictionary?
>
> On Sun, Apr 5, 2015 at 5:11 PM, Peter Haworth <pete at lcsql.com> wrote:
>
>> I'd guess the last of the options.
>>
>> The more I think about this, the more I think there should be mention of
>> this in the dictionary entry for repeat.
>>
>> It's a little like the ability to use a function to create a sortkey in the
>> sort command.  Nothing in the dictionary about that except for a user note.
>>
>> Pete
>> lcSQL Software <http://www.lcsql.com>
>> Home of lcStackBrowser <http://www.lcsql.com/lcstackbrowser.html> and
>> SQLiteAdmin <http://www.lcsql.com/sqliteadmin.html>
>>
>> On Sun, Apr 5, 2015 at 3:40 PM, Mike Bonner <bonnmike at gmail.com> wrote:
>>
>>> Yeah, kinda makes sense that it would work that way. Grab the data from
>> the
>>> container once, do magic things behind the scenes to get it ready to go,
>>> then loop through the lines.  I guess it could work either way though,
>>> where it uses byte offsets to get the next chunk, which would have made
>> the
>>> function method really suck for large data sets.
>>>
>>> Now I'm curious.. what exactly does repeat for each do?  Split on cr,
>> sort
>>> the keys and increment each loop to pop out the right line from the
>> array?
>>> Store all the data in a temp variable and read each line (item, char) by
>>> start/end position?
>>>
>>> On Sun, Apr 5, 2015 at 4:19 PM, Jerry Jensen <jhj at jhj.com> wrote:
>>>
>>>> Hi Mike,
>>>>
>>>>> On Apr 5, 2015, at 12:31 PM, Mike Bonner <bonnmike at gmail.com> wrote:
>>>>>
>>>>> While not exactly whats been requested, this works pretty well:
>>>>>
>>>>>     repeat for each line tLine in (myFilter(sData,"abc*","with"))
>>>>>
>>>>> I like the way a where clause reads as in the OP, but being able to
>> use
>>>> an
>>>>> inline function for data generation is rather powerful, and if all
>> you
>>>> need
>>>>> is a filter, setting up a function to do so is pretty straight
>> forward.
>>>>
>>>> Good trick! I didn't know you could do that either.
>>>>
>>>> I wondered if the function was called just once, or on every repeat.
>> Your
>>>> exapmle wouldn't tell, because the function would return the same stuff
>>>> every time.
>>>>
>>>> So I tested it. The answer is that the function is called only once.
>>> Good!
>>>>
>>>> global gCount
>>>>
>>>> on mouseUp
>>>>     global gCount
>>>>     put 0 into gCount
>>>>     repeat for each line L in mylines()
>>>>        put L & cr after msg
>>>>     end repeat
>>>>     put gCount after msg -- how many times mulines() was called
>>>> end mouseUp"
>>>>
>>>> function mylines
>>>>     global gCount
>>>>     add 1 to gCount
>>>>     return "1" & cr & "2" & cr & "3" & cr
>>>> end mylines
>>>>
>>>>