valueDiff for arrays?

classic Classic list List threaded Threaded
135 messages Options
1234567
Reply | Threaded
Open this post in threaded view
|

Re: valueDiff for arrays?

Trevor DeVore via use-livecode
Just to throw it out there I still want to add `each` to filter one day. So in this case I think it would be:

filter keys of tArray1 with expression \
      each is among the keys of tArray2 and \
      tArray1[each] is not tArray2[each]

> On 5 Aug 2018, at 11:23 am, Brian Milby via use-livecode <[hidden email]> wrote:
>
> Here is code that only uses LCS to accomplish the goal (only returning the
> keys where they exist in both arrays but the values are different).  This
> is made to be similar to the way the existing functions work (with the
> option to mutate).
>
> command valueDiff @pDestinationA, @pLeftA, pRightA
>   local tMutate, tLeft, tRight, tNewRight
>   if the paramCount is 3 then
>      put false into tMutate
>      put pLeftA into tLeft
>      put pRightA into tRight
>   else
>      put true into tMutate
>      put pDestinationA into tLeft
>      put pLeftA into tRight
>   end if
>   repeat for each key tKey in tLeft
>      if tKey is among the keys of tRight and \
>            tLeft[tKey] is not tRight[tKey] then
>         put tRight[tKey] into tNewRight[tKey]
>         next repeat
>      end if
>      delete variable tLeft[tKey]
>   end repeat
>   if tMutate then
>      put tLeft into pDestinationA
>      put tNewRight into pLeftA
>   else
>      put tLeft into pDestinationA["1"]
>      put tNewRight into pDestinationA["2"]
>   end if
> end valueDiff
>
> My question from an engine perspective is whether it would be faster to
> just generate both arrays instead of removing keys from tLeft.  I decided
> to build the tNewRight to avoid iterating the keys of tRight.
>
> I'd be pretty confident that Mark's solution will be faster, even with 3
> iterations over the keys.
>
> On Sat, Aug 4, 2018 at 6:52 PM, Mark Waddingham via use-livecode <
> [hidden email]> wrote:
>
>> On 2018-08-04 21:00, Richard Gaskin via use-livecode wrote:
>>
>>> Mark Waddingham wrote:
>>>
>>> Yes - so come up with LCS handlers which do that, share them, let's
>>>> work together to make them as efficient in LCS as possible and then
>>>> see what we can do in the engine to improve their performance (which
>>>> I'm guessing is as much the purpose for the proposition as the
>>>> syntax).
>>>>
>>>
>>> It is, primarily.  The minor convenience is nice too, but you know how
>>> much I love to see performance enhancements in the engine.
>>>
>>> As for implementation, Mark Wieder's looks good:
>>> http://lists.runrev.com/pipermail/use-livecode/2018-August/248862.html
>>>
>>
>> One important point here (which I think is something which is often
>> overlooked in LC as it is just something we deal with implicitly case by
>> case)...
>>
>> In your use-case for 'valueDiff' - do you need to tell the difference
>> between a key value being the empty string and a key value not being
>> present at all?
>>
>> [ i.e. using an array key absence to emulate 'nothing': meaning you are
>> actually storing nothing or a value (even the empty string). ]
>>
>> It might seem like a minor detail, but does change the operation somewhat
>> (and potential implementations).
>>
>> Warmest Regards,
>>
>> Mark.
>>
>> --
>> Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
>> LiveCode: Everyone can create apps
>>
>> _______________________________________________
>> use-livecode mailing list
>> [hidden email]
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: valueDiff for arrays?

Trevor DeVore via use-livecode
In reply to this post by Trevor DeVore via use-livecode
On 08/04/2018 04:45 PM, Mark Waddingham via use-livecode wrote:

> The other place this could come to bear is making the S/B (or some
> variant there-of) not only work to produce an application, but also a
> 'component/extension' - i.e. a distributable 'compiled' (in some sense)
> form of a collection of script only stacks which were much more easily
> distributable.

Hmmm... a 'bundle' of script-only stacks as a text file, especially if I
could attach it as a substack is very appealing. This is certainly a
need for stacks I distribute as stacks... for example, you can't use
revOnline for script-only stacks or for LCB code.

> Hehe - well it is a working day for me today, and tomorrow and the next
> week - I'm currently in Dallas, Texas, for FileMaker DevCon.

My condolences <g>

--
  Mark Wieder
  [hidden email]

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: valueDiff for arrays?

Trevor DeVore via use-livecode
I think Mark's code had a typo (left returned too many keys), but even when
corrected it takes half the time as a pure LCS solution.  Here's my
modification:

function bwmValueDiff pLeft, pRight
   local tResult
   intersect pLeft with pRight into tResult["1"]
   repeat for each key tKey in tResult["1"]
      if pLeft[tKey] is pRight[tKey] then
         delete variable tResult["1"][tKey]
      end if
   end repeat
   intersect pRight with tResult["1"] into tResult["2"]
   return tResult
end bwmValueDiff


On Sat, Aug 4, 2018 at 9:01 PM, Mark Wieder via use-livecode <
[hidden email]> wrote:

> On 08/04/2018 04:45 PM, Mark Waddingham via use-livecode wrote:
>
> The other place this could come to bear is making the S/B (or some variant
>> there-of) not only work to produce an application, but also a
>> 'component/extension' - i.e. a distributable 'compiled' (in some sense)
>> form of a collection of script only stacks which were much more easily
>> distributable.
>>
>
> Hmmm... a 'bundle' of script-only stacks as a text file, especially if I
> could attach it as a substack is very appealing. This is certainly a need
> for stacks I distribute as stacks... for example, you can't use revOnline
> for script-only stacks or for LCB code.
>
> Hehe - well it is a working day for me today, and tomorrow and the next
>> week - I'm currently in Dallas, Texas, for FileMaker DevCon.
>>
>
> My condolences <g>
>
> --
>  Mark Wieder
>  [hidden email]
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: valueDiff for arrays?

Trevor DeVore via use-livecode
On 08/04/2018 07:11 PM, Brian Milby via use-livecode wrote:
> I think Mark's code had a typo (left returned too many keys), but even when
> corrected it takes half the time as a pure LCS solution.  Here's my
> modification:

Quite right. Good catch.

--
  Mark Wieder
  [hidden email]

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: valueDiff for arrays?

Trevor DeVore via use-livecode
In reply to this post by Trevor DeVore via use-livecode
On 08/04/2018 12:20 PM, J. Landman Gay via use-livecode wrote:
> On 8/4/18 12:41 PM, Mark Waddingham via use-livecode wrote:
>> Can you immediately see the error?
>
> Who, me? LOL. Well, I did find the line that was different. Brian and
> others who can read this stuff did better. But I did get the gist of
> your post and feel sufficiently smug now.

Careful with that. Smugness is the main way those things get messed up
in the first place.

--
  Mark Wieder
  [hidden email]

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: valueDiff for arrays?

Trevor DeVore via use-livecode
I have not been able to locate the earlier conversation on pass by
reference vice value.  I did a quick test and it took 100,000 loops to be
able to get a difference that was obvious.  My test was to construct simple
functions that took 1 to 3 parameters.  3 functions used all pass by value,
3 functions used all pass by reference.  Code inside the function added 1
to each parameter and returned the first.  The pass by reference function
was consistently around 40ms faster than the matching value function.
Making the functions private made them slightly faster but the delta was
about the same.  All of the values in this test were numeric.  Those
differences seem smaller that I recall, so I will do some additional test
with arrays and strings.
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: valueDiff for arrays?

Trevor DeVore via use-livecode
In reply to this post by Trevor DeVore via use-livecode


> On 5 Aug 2018, at 11:59 am, Monte Goulding via use-livecode <[hidden email]> wrote:
>
> Just to throw it out there I still want to add `each` to filter one day. So in this case I think it would be:
>
> filter keys of tArray1 with expression \
>      each is among the keys of tArray2 and \
>      tArray1[each] is not tArray2[each]


Given I have been wanting to do ^ for a couple of years I decided to just go ahead and do it… might be a while before we have time to bikeshed the syntax though.

https://github.com/livecode/livecode/pull/6626 <https://github.com/livecode/livecode/pull/6626>

Examples:
local tFoo,tBar
put "foo" into tFoo[1]
put "bar" into tFoo[2]
put "baz" into tBar[1]
put "bar" into tBar[2]
filter keys of tFoo with expression tFoo[each] is tBar[each]
— tFoo now has one key 2 which is `bar`

put “yes,foo” & return & “no,bar” into tFoo
filter lines of tFoo with expression item 1 of each is “yes”

We could feasibly not use `with|without` for this forcing the expression to return true to filter. If we went that way then perhaps `where` would be nicest?

filter lines of tFoo where item 1 of each is “yes”

Cheers

Monte

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: valueDiff for arrays?

Trevor DeVore via use-livecode
In reply to this post by Trevor DeVore via use-livecode
On 2018-08-05 03:59, Monte Goulding via use-livecode wrote:
> Just to throw it out there I still want to add `each` to filter one
> day. So in this case I think it would be:
>
> filter keys of tArray1 with expression \
>       each is among the keys of tArray2 and \
>       tArray1[each] is not tArray2[each]

Not quite - if I understand Richard's request correctly, and the code
which has been presented
then it cannot be done by a single filter on one array.

The result he is asking for requires information from both arrays, some
of which may not be shared.

The above only contains information from tArray1.

Warmest Regards,

Mark.

--
Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: valueDiff for arrays?

Trevor DeVore via use-livecode
In reply to this post by Trevor DeVore via use-livecode
On 2018-08-05 07:31, Monte Goulding via use-livecode wrote:

> Given I have been wanting to do ^ for a couple of years I decided to
> just go ahead and do it… might be a while before we have time to
> bikeshed the syntax though.
>
> https://github.com/livecode/livecode/pull/6626
> <https://github.com/livecode/livecode/pull/6626>
>
> Examples:
> local tFoo,tBar
> put "foo" into tFoo[1]
> put "bar" into tFoo[2]
> put "baz" into tBar[1]
> put "bar" into tBar[2]
> filter keys of tFoo with expression tFoo[each] is tBar[each]
> — tFoo now has one key 2 which is `bar`
>
> put “yes,foo” & return & “no,bar” into tFoo
> filter lines of tFoo with expression item 1 of each is “yes”
>
> We could feasibly not use `with|without` for this forcing the
> expression to return true to filter. If we went that way then perhaps
> `where` would be nicest?
>
> filter lines of tFoo where item 1 of each is “yes”

Geez @Monte - you do like creating work for me don't you! ;)

In terms of syntax - definitely not 'with expression' - that's ghastly.
It is a 'where' clause - in the same vein as SQL and other query
languages - so no bike-shedding required there (also, pleasingly, all
other 'filter' types become sugar for a where clause using operators
which the language does not have yet - but obviously we have the code
for...).

If we are going to bike-shed over syntax - can we do so over the use of
'filter' itself. I don't know why but I have a complete mental block
about it - regardless of how many times I use it or read it - I always
have to 'double-think' to work out what form to use - is that just me?

   filter <things> of X with Y
   filter <things> of X without Y

I couldn't tell you just by looking *what* they actually do. I'm not
sure why but I think the verb is actually wrong - in all cases you have
a set of things and you are either keeping an element, or removing an
element... So I wonder if:

   keep <things> of X where Y
   discard <things> of X where Y

(I'm not particularly attached to keep/discard - but it does need to be
a pair of 'true' antonyms which don't intersect with any other 'core'
pairs of such things we have).

Might be more appropriate?

Of course, maybe it is just 'with' / 'without' are inappropriate, and
'where' might actually help me retrain my mind to see with/without as
the sugar they truly are.

Anyway, thought it worth throwing out there to see what people think?

Warmest Regards,

Mark.

--
Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: valueDiff for arrays?

Trevor DeVore via use-livecode
Current

filter [{lines | items | keys | elements} of] filterSource {with | without | [not] matching} [{wildcard pattern | regex pattern}] filterPattern [into targetContainer]

Possible Suggestion

filter [{lines | items | keys | elements} of] filterSource {{with | without | [not] matching} [{wildcard | regex}] filterPattern | where filterExpression} [into targetContainer]

“matching” was added in 6 which would probably be clearer.

Thanks,
Brian

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: valueDiff for arrays?

Trevor DeVore via use-livecode
In reply to this post by Trevor DeVore via use-livecode
Or to include new modifiers:
{keeping | discarding | with | without | [not] matching}

Which if not using the “into” form the first two make the statement much clearer as to the intent.

Thanks,
Brian

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: valueDiff for arrays?

Trevor DeVore via use-livecode
In reply to this post by Trevor DeVore via use-livecode
Probably better:


filter [{lines | items | keys | elements} of] filterSource {keeping | discarding | with | without | [not] matching} {[{wildcard | regex} pattern] filterPattern | where filterExpression} [into targetContainer]


So Monte’s example would be:
filter keys of tFoo keeping where tFoo[each] is not tBar[each]
(And to get Richard’s result you would need to follow this by an intersect each way. The filter would replace the repeat loop in Mark’s solution)


Even though “with where” would be syntactically correct, the preferred usage would be “keeping where”.

Thanks,
Brian
On Aug 5, 2018, 7:32 AM -0500, Mark Waddingham via use-livecode <[hidden email]>, wrote:

> On 2018-08-05 07:31, Monte Goulding via use-livecode wrote:
> > Given I have been wanting to do ^ for a couple of years I decided to
> > just go ahead and do it… might be a while before we have time to
> > bikeshed the syntax though.
> >
> > https://github.com/livecode/livecode/pull/6626
> > <https://github.com/livecode/livecode/pull/6626>
> >
> > Examples:
> > local tFoo,tBar
> > put "foo" into tFoo[1]
> > put "bar" into tFoo[2]
> > put "baz" into tBar[1]
> > put "bar" into tBar[2]
> > filter keys of tFoo with expression tFoo[each] is tBar[each]
> > — tFoo now has one key 2 which is `bar`
> >
> > put “yes,foo” & return & “no,bar” into tFoo
> > filter lines of tFoo with expression item 1 of each is “yes”
> >
> > We could feasibly not use `with|without` for this forcing the
> > expression to return true to filter. If we went that way then perhaps
> > `where` would be nicest?
> >
> > filter lines of tFoo where item 1 of each is “yes”
>
> Geez @Monte - you do like creating work for me don't you! ;)
>
> In terms of syntax - definitely not 'with expression' - that's ghastly.
> It is a 'where' clause - in the same vein as SQL and other query
> languages - so no bike-shedding required there (also, pleasingly, all
> other 'filter' types become sugar for a where clause using operators
> which the language does not have yet - but obviously we have the code
> for...).
>
> If we are going to bike-shed over syntax - can we do so over the use of
> 'filter' itself. I don't know why but I have a complete mental block
> about it - regardless of how many times I use it or read it - I always
> have to 'double-think' to work out what form to use - is that just me?
>
> filter <things> of X with Y
> filter <things> of X without Y
>
> I couldn't tell you just by looking *what* they actually do. I'm not
> sure why but I think the verb is actually wrong - in all cases you have
> a set of things and you are either keeping an element, or removing an
> element... So I wonder if:
>
> keep <things> of X where Y
> discard <things> of X where Y
>
> (I'm not particularly attached to keep/discard - but it does need to be
> a pair of 'true' antonyms which don't intersect with any other 'core'
> pairs of such things we have).
>
> Might be more appropriate?
>
> Of course, maybe it is just 'with' / 'without' are inappropriate, and
> 'where' might actually help me retrain my mind to see with/without as
> the sugar they truly are.
>
> Anyway, thought it worth throwing out there to see what people think?
>
> Warmest Regards,
>
> Mark.
>
> --
> Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: valueDiff for arrays?

Trevor DeVore via use-livecode
In reply to this post by Trevor DeVore via use-livecode
On 2018-08-05 16:00, Brian Milby wrote:
> Or to include new modifiers:
>  {keeping | discarding | with | without | [not] matching}
>
>  Which if not using the “into” form the first two make the
> statement much clearer as to the intent.

So, I figured out my 'cognitive dissonance' on filter. The issue is that
'filter' by itself is not sufficient to suggest the operation the filter
is performing - it is too general a term. However...

I think Brian's suggestion of modifiers is actually much closer to the
most appropriate syntax because they naturally work well with or without
an 'into' clause. Contrast (with a minor tweak to @Brian's suggestion):

keep lines of X [ where | matching | not matching ] Y -- seems okay
keep lines of X [ where | matching | not matching ] Y into Z -- seems
contorted

discard lines of X [ where | matching | not matching ] Y -- seems okay
discard lines of X [ where | matching | not matching ] Y into Z --
ambiguous, are the discarded lines going into Z, or the ones which
aren't discarded?

In contrast here are two potential forms with modifiers:

A: filter X by ( keeping | discarding ) lines ( where | [ not ] matching
| with | without ) Y [ into Z ]

B: filter lines of X by keeping those ( where | [ not ] matching | with
| without ) Y [ into Z ]

In terms of these (A) I think is preferable - simply because we already
use 'by' in the language - rather than 'those'; further it strongly
suggests that the process 'moves' X to Z - by parsing the chunks of X
through some filter defined by Y.

The actual fundamental operation here is:

   Filter(source, chunk, predicate, target)

Where predicate is formed as follows (assuming we had operators matching
wildcard / matching pattern!):

   keeping where P -> P
   keeping with P -> each matches wildcard P
   keeping without P -> not (each matches wildcard P)
   keeping matching P -> each matches pattern P
   keeping not matching P -> not (each matches wildcard P)

   discarding where P -> not P
   discarding with P -> not (each matches wildcard P)
   discarding without P -> each matches wildcard P
   discarding matching P -> not (each matches pattern P)
   discarding not matching P -> each matches wildcard P

So the actual underling operation is the same: P is a boolean predicate
operating on 'each', where each is taken to be each 'chunk' of X in
turn; if P(each) returns true, the element is kept, otherwise it is
discarded.

I quite like the above - it has a very simple underbelly (a single
operation!), but the actual English-like syntax is a true and correct
sentence.

What do people think?

Warmest Regards,

Mark.

--
Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: valueDiff for arrays?

Trevor DeVore via use-livecode
I like A. Here is my take on the actual dictionary syntax:

filter filterSource by {keeping | discarding} [{lines | items | keys | elements}] {{with | without | [not] matching} {[{wildcard | regex} pattern] filterPattern | where filterExpression} [into targetContainer]

Not sure about leaving the chunk type optional. It would make readability less obvious but no less than today.

My guess is that retaining the earlier form (backwards compatibility) would be easy since the parser just needs to switch based on the third token being “by”. The new form would be placed as the first one checked to make it the fastest to parse.

Thanks,
Brian
On Aug 5, 2018, 9:38 AM -0500, Mark Waddingham via use-livecode <[hidden email]>, wrote:

> On 2018-08-05 16:00, Brian Milby wrote:
> > Or to include new modifiers:
> > {keeping | discarding | with | without | [not] matching}
> >
> > Which if not using the “into” form the first two make the
> > statement much clearer as to the intent.
>
> So, I figured out my 'cognitive dissonance' on filter. The issue is that
> 'filter' by itself is not sufficient to suggest the operation the filter
> is performing - it is too general a term. However...
>
> I think Brian's suggestion of modifiers is actually much closer to the
> most appropriate syntax because they naturally work well with or without
> an 'into' clause. Contrast (with a minor tweak to @Brian's suggestion):
>
> keep lines of X [ where | matching | not matching ] Y -- seems okay
> keep lines of X [ where | matching | not matching ] Y into Z -- seems
> contorted
>
> discard lines of X [ where | matching | not matching ] Y -- seems okay
> discard lines of X [ where | matching | not matching ] Y into Z --
> ambiguous, are the discarded lines going into Z, or the ones which
> aren't discarded?
>
> In contrast here are two potential forms with modifiers:
>
> A: filter X by ( keeping | discarding ) lines ( where | [ not ] matching
> | with | without ) Y [ into Z ]
>
> B: filter lines of X by keeping those ( where | [ not ] matching | with
> | without ) Y [ into Z ]
>
> In terms of these (A) I think is preferable - simply because we already
> use 'by' in the language - rather than 'those'; further it strongly
> suggests that the process 'moves' X to Z - by parsing the chunks of X
> through some filter defined by Y.
>
> The actual fundamental operation here is:
>
> Filter(source, chunk, predicate, target)
>
> Where predicate is formed as follows (assuming we had operators matching
> wildcard / matching pattern!):
>
> keeping where P -> P
> keeping with P -> each matches wildcard P
> keeping without P -> not (each matches wildcard P)
> keeping matching P -> each matches pattern P
> keeping not matching P -> not (each matches wildcard P)
>
> discarding where P -> not P
> discarding with P -> not (each matches wildcard P)
> discarding without P -> each matches wildcard P
> discarding matching P -> not (each matches pattern P)
> discarding not matching P -> each matches wildcard P
>
> So the actual underling operation is the same: P is a boolean predicate
> operating on 'each', where each is taken to be each 'chunk' of X in
> turn; if P(each) returns true, the element is kept, otherwise it is
> discarded.
>
> I quite like the above - it has a very simple underbelly (a single
> operation!), but the actual English-like syntax is a true and correct
> sentence.
>
> What do people think?
>
> Warmest Regards,
>
> Mark.
>
> --
> Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: valueDiff for arrays?

Trevor DeVore via use-livecode
In reply to this post by Trevor DeVore via use-livecode
This is getting pretty contorted and is becoming less like natural
language. For what it's worth, I have never been confused by the current
use of filter. I think of it as pouring soup through a wire strainer.
Filtering "with" keeps the solids. Filtering "without" dumps them and keeps
the liquid.

Maybe I cook too much. In any case, the solids (what remains after
filtering) are the things you're either keeping or discarding.
--
Jacqueline Landman Gay | [hidden email]
HyperActive Software | http://www.hyperactivesw.com
On August 5, 2018 9:38:45 AM Brian Milby via use-livecode
<[hidden email]> wrote:

> Probably better:
>
>
> filter [{lines | items | keys | elements} of] filterSource {keeping |
> discarding | with | without | [not] matching} {[{wildcard | regex} pattern]
> filterPattern | where filterExpression} [into targetContainer]
>
>
> So Monte’s example would be:
> filter keys of tFoo keeping where tFoo[each] is not tBar[each]
> (And to get Richard’s result you would need to follow this by an intersect
> each way. The filter would replace the repeat loop in Mark’s solution)
>
>
> Even though “with where” would be syntactically correct, the preferred
> usage would be “keeping where”.
>
> Thanks,
> Brian
> On Aug 5, 2018, 7:32 AM -0500, Mark Waddingham via use-livecode
> <[hidden email]>, wrote:
>> On 2018-08-05 07:31, Monte Goulding via use-livecode wrote:
>> > Given I have been wanting to do ^ for a couple of years I decided to
>> > just go ahead and do it… might be a while before we have time to
>> > bikeshed the syntax though.
>> >
>> > https://github.com/livecode/livecode/pull/6626
>> > <https://github.com/livecode/livecode/pull/6626>
>> >
>> > Examples:
>> > local tFoo,tBar
>> > put "foo" into tFoo[1]
>> > put "bar" into tFoo[2]
>> > put "baz" into tBar[1]
>> > put "bar" into tBar[2]
>> > filter keys of tFoo with expression tFoo[each] is tBar[each]
>> > — tFoo now has one key 2 which is `bar`
>> >
>> > put “yes,foo” & return & “no,bar” into tFoo
>> > filter lines of tFoo with expression item 1 of each is “yes”
>> >
>> > We could feasibly not use `with|without` for this forcing the
>> > expression to return true to filter. If we went that way then perhaps
>> > `where` would be nicest?
>> >
>> > filter lines of tFoo where item 1 of each is “yes”
>>
>> Geez @Monte - you do like creating work for me don't you! ;)
>>
>> In terms of syntax - definitely not 'with expression' - that's ghastly.
>> It is a 'where' clause - in the same vein as SQL and other query
>> languages - so no bike-shedding required there (also, pleasingly, all
>> other 'filter' types become sugar for a where clause using operators
>> which the language does not have yet - but obviously we have the code
>> for...).
>>
>> If we are going to bike-shed over syntax - can we do so over the use of
>> 'filter' itself. I don't know why but I have a complete mental block
>> about it - regardless of how many times I use it or read it - I always
>> have to 'double-think' to work out what form to use - is that just me?
>>
>> filter <things> of X with Y
>> filter <things> of X without Y
>>
>> I couldn't tell you just by looking *what* they actually do. I'm not
>> sure why but I think the verb is actually wrong - in all cases you have
>> a set of things and you are either keeping an element, or removing an
>> element... So I wonder if:
>>
>> keep <things> of X where Y
>> discard <things> of X where Y
>>
>> (I'm not particularly attached to keep/discard - but it does need to be
>> a pair of 'true' antonyms which don't intersect with any other 'core'
>> pairs of such things we have).
>>
>> Might be more appropriate?
>>
>> Of course, maybe it is just 'with' / 'without' are inappropriate, and
>> 'where' might actually help me retrain my mind to see with/without as
>> the sugar they truly are.
>>
>> Anyway, thought it worth throwing out there to see what people think?
>>
>> Warmest Regards,
>>
>> Mark.
>>
>> --
>> Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
>> LiveCode: Everyone can create apps
>>
>> _______________________________________________
>> use-livecode mailing list
>> [hidden email]
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode




_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: valueDiff for arrays?

Trevor DeVore via use-livecode
On 2018-08-05 17:36, J. Landman Gay via use-livecode wrote:
> This is getting pretty contorted and is becoming less like natural
> language. For what it's worth, I have never been confused by the
> current use of filter. I think of it as pouring soup through a wire
> strainer. Filtering "with" keeps the solids. Filtering "without" dumps
> them and keeps the liquid.

I honestly can't see how:

filter lines of X with Y

Is less contorted and more natural language than:

filter X by keeping lines matching Y

The former *requires* 'arcane' knowledge to comprehend (it is a
significant contraction of concepts - you need to know the contractions
precisely to understand it!) - the latter does precisely what it says -
it is actually a fully correct and full English sentence...

Warmest Regards,

Mark.

--
Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: valueDiff for arrays?

Trevor DeVore via use-livecode
In reply to this post by Trevor DeVore via use-livecode
Maybe 'strain' could be a culinary synonym?
;-)

Best wishes

David Glasgow

Sent from my  iPad via iBrain & iFingers

LinkedIn

> On 5 Aug 2018, at 16:36, J. Landman Gay via use-livecode <[hidden email]> wrote:
>
> This is getting pretty contorted and is becoming less like natural language. For what it's worth, I have never been confused by the current use of filter. I think of it as pouring soup through a wire strainer. Filtering "with" keeps the solids. Filtering "without" dumps them and keeps the liquid.
>
> Maybe I cook too much. In any case, the solids (what remains after filtering) are the things you're either keeping or discarding.
> --
> Jacqueline Landman Gay | [hidden email]
> HyperActive Software | http://www.hyperactivesw.com
>> On August 5, 2018 9:38:45 AM Brian Milby via use-livecode <[hidden email]> wrote:
>>
>> Probably better:
>>
>>
>> filter [{lines | items | keys | elements} of] filterSource {keeping | discarding | with | without | [not] matching} {[{wildcard | regex} pattern] filterPattern | where filterExpression} [into targetContainer]
>>
>>
>> So Monte’s example would be:
>> filter keys of tFoo keeping where tFoo[each] is not tBar[each]
>> (And to get Richard’s result you would need to follow this by an intersect each way. The filter would replace the repeat loop in Mark’s solution)
>>
>>
>> Even though “with where” would be syntactically correct, the preferred usage would be “keeping where”.
>>
>> Thanks,
>> Brian
>>> On Aug 5, 2018, 7:32 AM -0500, Mark Waddingham via use-livecode <[hidden email]>, wrote:
>>> On 2018-08-05 07:31, Monte Goulding via use-livecode wrote:
>>> > Given I have been wanting to do ^ for a couple of years I decided to
>>> > just go ahead and do it… might be a while before we have time to
>>> > bikeshed the syntax though.
>>> >
>>> > https://github.com/livecode/livecode/pull/6626
>>> > <https://github.com/livecode/livecode/pull/6626>
>>> >
>>> > Examples:
>>> > local tFoo,tBar
>>> > put "foo" into tFoo[1]
>>> > put "bar" into tFoo[2]
>>> > put "baz" into tBar[1]
>>> > put "bar" into tBar[2]
>>> > filter keys of tFoo with expression tFoo[each] is tBar[each]
>>> > — tFoo now has one key 2 which is `bar`
>>> >
>>> > put “yes,foo” & return & “no,bar” into tFoo
>>> > filter lines of tFoo with expression item 1 of each is “yes”
>>> >
>>> > We could feasibly not use `with|without` for this forcing the
>>> > expression to return true to filter. If we went that way then perhaps
>>> > `where` would be nicest?
>>> >
>>> > filter lines of tFoo where item 1 of each is “yes”
>>>
>>> Geez @Monte - you do like creating work for me don't you! ;)
>>>
>>> In terms of syntax - definitely not 'with expression' - that's ghastly.
>>> It is a 'where' clause - in the same vein as SQL and other query
>>> languages - so no bike-shedding required there (also, pleasingly, all
>>> other 'filter' types become sugar for a where clause using operators
>>> which the language does not have yet - but obviously we have the code
>>> for...).
>>>
>>> If we are going to bike-shed over syntax - can we do so over the use of
>>> 'filter' itself. I don't know why but I have a complete mental block
>>> about it - regardless of how many times I use it or read it - I always
>>> have to 'double-think' to work out what form to use - is that just me?
>>>
>>> filter <things> of X with Y
>>> filter <things> of X without Y
>>>
>>> I couldn't tell you just by looking *what* they actually do. I'm not
>>> sure why but I think the verb is actually wrong - in all cases you have
>>> a set of things and you are either keeping an element, or removing an
>>> element... So I wonder if:
>>>
>>> keep <things> of X where Y
>>> discard <things> of X where Y
>>>
>>> (I'm not particularly attached to keep/discard - but it does need to be
>>> a pair of 'true' antonyms which don't intersect with any other 'core'
>>> pairs of such things we have).
>>>
>>> Might be more appropriate?
>>>
>>> Of course, maybe it is just 'with' / 'without' are inappropriate, and
>>> 'where' might actually help me retrain my mind to see with/without as
>>> the sugar they truly are.
>>>
>>> Anyway, thought it worth throwing out there to see what people think?
>>>
>>> Warmest Regards,
>>>
>>> Mark.
>>>
>>> --
>>> Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
>>> LiveCode: Everyone can create apps
>>>
>>> _______________________________________________
>>> use-livecode mailing list
>>> [hidden email]
>>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>> _______________________________________________
>> use-livecode mailing list
>> [hidden email]
>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: valueDiff for arrays?

Trevor DeVore via use-livecode
Well...

strain X through Y

Does kind of work - although it still doesn't explicitly relate what is to be kept (which is implicit in context in a recipe) and that's the deficiency in the current syntax.

We can make all parts optional in the new proposed form which would mean you can still write a significant contraction. However, by being verbose you can make the command a complete representation of what is being done without needing to understand the context of the operation (which means code which is more verbose is much more quickly readable).

Anyway, maybe when we finally get to open language we can have a culinary based variant syntax ;)

Warmest Regards,

Mark.

Sent from my iPhone

> On 5 Aug 2018, at 11:23, David Glasgow via use-livecode <[hidden email]> wrote:
>
> Maybe 'strain' could be a culinary synonym?
> ;-)
>
> Best wishes
>
> David Glasgow
>
> Sent from my  iPad via iBrain & iFingers
>
> LinkedIn
>
>> On 5 Aug 2018, at 16:36, J. Landman Gay via use-livecode <[hidden email]> wrote:
>>
>> This is getting pretty contorted and is becoming less like natural language. For what it's worth, I have never been confused by the current use of filter. I think of it as pouring soup through a wire strainer. Filtering "with" keeps the solids. Filtering "without" dumps them and keeps the liquid.
>>
>> Maybe I cook too much. In any case, the solids (what remains after filtering) are the things you're either keeping or discarding.
>> --
>> Jacqueline Landman Gay | [hidden email]
>> HyperActive Software | http://www.hyperactivesw.com
>>> On August 5, 2018 9:38:45 AM Brian Milby via use-livecode <[hidden email]> wrote:
>>>
>>> Probably better:
>>>
>>>
>>> filter [{lines | items | keys | elements} of] filterSource {keeping | discarding | with | without | [not] matching} {[{wildcard | regex} pattern] filterPattern | where filterExpression} [into targetContainer]
>>>
>>>
>>> So Monte’s example would be:
>>> filter keys of tFoo keeping where tFoo[each] is not tBar[each]
>>> (And to get Richard’s result you would need to follow this by an intersect each way. The filter would replace the repeat loop in Mark’s solution)
>>>
>>>
>>> Even though “with where” would be syntactically correct, the preferred usage would be “keeping where”.
>>>
>>> Thanks,
>>> Brian
>>>> On Aug 5, 2018, 7:32 AM -0500, Mark Waddingham via use-livecode <[hidden email]>, wrote:
>>>>> On 2018-08-05 07:31, Monte Goulding via use-livecode wrote:
>>>>> Given I have been wanting to do ^ for a couple of years I decided to
>>>>> just go ahead and do it… might be a while before we have time to
>>>>> bikeshed the syntax though.
>>>>>
>>>>> https://github.com/livecode/livecode/pull/6626
>>>>> <https://github.com/livecode/livecode/pull/6626>
>>>>>
>>>>> Examples:
>>>>> local tFoo,tBar
>>>>> put "foo" into tFoo[1]
>>>>> put "bar" into tFoo[2]
>>>>> put "baz" into tBar[1]
>>>>> put "bar" into tBar[2]
>>>>> filter keys of tFoo with expression tFoo[each] is tBar[each]
>>>>> — tFoo now has one key 2 which is `bar`
>>>>>
>>>>> put “yes,foo” & return & “no,bar” into tFoo
>>>>> filter lines of tFoo with expression item 1 of each is “yes”
>>>>>
>>>>> We could feasibly not use `with|without` for this forcing the
>>>>> expression to return true to filter. If we went that way then perhaps
>>>>> `where` would be nicest?
>>>>>
>>>>> filter lines of tFoo where item 1 of each is “yes”
>>>>
>>>> Geez @Monte - you do like creating work for me don't you! ;)
>>>>
>>>> In terms of syntax - definitely not 'with expression' - that's ghastly.
>>>> It is a 'where' clause - in the same vein as SQL and other query
>>>> languages - so no bike-shedding required there (also, pleasingly, all
>>>> other 'filter' types become sugar for a where clause using operators
>>>> which the language does not have yet - but obviously we have the code
>>>> for...).
>>>>
>>>> If we are going to bike-shed over syntax - can we do so over the use of
>>>> 'filter' itself. I don't know why but I have a complete mental block
>>>> about it - regardless of how many times I use it or read it - I always
>>>> have to 'double-think' to work out what form to use - is that just me?
>>>>
>>>> filter <things> of X with Y
>>>> filter <things> of X without Y
>>>>
>>>> I couldn't tell you just by looking *what* they actually do. I'm not
>>>> sure why but I think the verb is actually wrong - in all cases you have
>>>> a set of things and you are either keeping an element, or removing an
>>>> element... So I wonder if:
>>>>
>>>> keep <things> of X where Y
>>>> discard <things> of X where Y
>>>>
>>>> (I'm not particularly attached to keep/discard - but it does need to be
>>>> a pair of 'true' antonyms which don't intersect with any other 'core'
>>>> pairs of such things we have).
>>>>
>>>> Might be more appropriate?
>>>>
>>>> Of course, maybe it is just 'with' / 'without' are inappropriate, and
>>>> 'where' might actually help me retrain my mind to see with/without as
>>>> the sugar they truly are.
>>>>
>>>> Anyway, thought it worth throwing out there to see what people think?
>>>>
>>>> Warmest Regards,
>>>>
>>>> Mark.
>>>>
>>>> --
>>>> Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
>>>> LiveCode: Everyone can create apps
>>>>
>>>> _______________________________________________
>>>> use-livecode mailing list
>>>> [hidden email]
>>>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>> _______________________________________________
>>> use-livecode mailing list
>>> [hidden email]
>>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
>>
>>
>>
>> _______________________________________________
>> use-livecode mailing list
>> [hidden email]
>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: valueDiff for arrays?

Trevor DeVore via use-livecode
In reply to this post by Trevor DeVore via use-livecode
Yes, yours is natural. Some of the others were stretching it a bit.
--
Jacqueline Landman Gay | [hidden email]
HyperActive Software | http://www.hyperactivesw.com
On August 5, 2018 11:10:47 AM Mark Waddingham via use-livecode
<[hidden email]> wrote:

> On 2018-08-05 17:36, J. Landman Gay via use-livecode wrote:
>> This is getting pretty contorted and is becoming less like natural
>> language. For what it's worth, I have never been confused by the
>> current use of filter. I think of it as pouring soup through a wire
>> strainer. Filtering "with" keeps the solids. Filtering "without" dumps
>> them and keeps the liquid.
>
> I honestly can't see how:
>
> filter lines of X with Y
>
> Is less contorted and more natural language than:
>
> filter X by keeping lines matching Y
>
> The former *requires* 'arcane' knowledge to comprehend (it is a
> significant contraction of concepts - you need to know the contractions
> precisely to understand it!) - the latter does precisely what it says -
> it is actually a fully correct and full English sentence...
>
> Warmest Regards,
>
> Mark.
>
> --
> Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode




_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: valueDiff for arrays?

Trevor DeVore via use-livecode
In reply to this post by Trevor DeVore via use-livecode
I think "filter" is culinary enough. Coffee filters do the same thing, only
they filter without. :)

--
Jacqueline Landman Gay | [hidden email]
HyperActive Software | http://www.hyperactivesw.com
On August 5, 2018 11:53:11 AM Mark Waddingham via use-livecode
<[hidden email]> wrote:

> Well...
>
> strain X through Y
>
> Does kind of work - although it still doesn't explicitly relate what is to
> be kept (which is implicit in context in a recipe) and that's the
> deficiency in the current syntax.
>
> We can make all parts optional in the new proposed form which would mean
> you can still write a significant contraction. However, by being verbose
> you can make the command a complete representation of what is being done
> without needing to understand the context of the operation (which means
> code which is more verbose is much more quickly readable).
>
> Anyway, maybe when we finally get to open language we can have a culinary
> based variant syntax ;)
>
> Warmest Regards,
>
> Mark.
>
> Sent from my iPhone
>
>> On 5 Aug 2018, at 11:23, David Glasgow via use-livecode
>> <[hidden email]> wrote:
>>
>> Maybe 'strain' could be a culinary synonym?
>> ;-)
>>
>> Best wishes
>>
>> David Glasgow
>>
>> Sent from my  iPad via iBrain & iFingers
>>
>> LinkedIn
>>
>>> On 5 Aug 2018, at 16:36, J. Landman Gay via use-livecode
>>> <[hidden email]> wrote:
>>>
>>> This is getting pretty contorted and is becoming less like natural
>>> language. For what it's worth, I have never been confused by the current
>>> use of filter. I think of it as pouring soup through a wire strainer.
>>> Filtering "with" keeps the solids. Filtering "without" dumps them and keeps
>>> the liquid.
>>>
>>> Maybe I cook too much. In any case, the solids (what remains after
>>> filtering) are the things you're either keeping or discarding.
>>> --
>>> Jacqueline Landman Gay | [hidden email]
>>> HyperActive Software | http://www.hyperactivesw.com
>>>> On August 5, 2018 9:38:45 AM Brian Milby via use-livecode
>>>> <[hidden email]> wrote:
>>>>
>>>> Probably better:
>>>>
>>>>
>>>> filter [{lines | items | keys | elements} of] filterSource {keeping |
>>>> discarding | with | without | [not] matching} {[{wildcard | regex} pattern]
>>>> filterPattern | where filterExpression} [into targetContainer]
>>>>
>>>>
>>>> So Monte’s example would be:
>>>> filter keys of tFoo keeping where tFoo[each] is not tBar[each]
>>>> (And to get Richard’s result you would need to follow this by an intersect
>>>> each way. The filter would replace the repeat loop in Mark’s solution)
>>>>
>>>>
>>>> Even though “with where” would be syntactically correct, the preferred
>>>> usage would be “keeping where”.
>>>>
>>>> Thanks,
>>>> Brian
>>>>> On Aug 5, 2018, 7:32 AM -0500, Mark Waddingham via use-livecode
>>>>> <[hidden email]>, wrote:
>>>>>> On 2018-08-05 07:31, Monte Goulding via use-livecode wrote:
>>>>>> Given I have been wanting to do ^ for a couple of years I decided to
>>>>>> just go ahead and do it… might be a while before we have time to
>>>>>> bikeshed the syntax though.
>>>>>>
>>>>>> https://github.com/livecode/livecode/pull/6626
>>>>>> <https://github.com/livecode/livecode/pull/6626>
>>>>>>
>>>>>> Examples:
>>>>>> local tFoo,tBar
>>>>>> put "foo" into tFoo[1]
>>>>>> put "bar" into tFoo[2]
>>>>>> put "baz" into tBar[1]
>>>>>> put "bar" into tBar[2]
>>>>>> filter keys of tFoo with expression tFoo[each] is tBar[each]
>>>>>> — tFoo now has one key 2 which is `bar`
>>>>>>
>>>>>> put “yes,foo” & return & “no,bar” into tFoo
>>>>>> filter lines of tFoo with expression item 1 of each is “yes”
>>>>>>
>>>>>> We could feasibly not use `with|without` for this forcing the
>>>>>> expression to return true to filter. If we went that way then perhaps
>>>>>> `where` would be nicest?
>>>>>>
>>>>>> filter lines of tFoo where item 1 of each is “yes”
>>>>>
>>>>> Geez @Monte - you do like creating work for me don't you! ;)
>>>>>
>>>>> In terms of syntax - definitely not 'with expression' - that's ghastly.
>>>>> It is a 'where' clause - in the same vein as SQL and other query
>>>>> languages - so no bike-shedding required there (also, pleasingly, all
>>>>> other 'filter' types become sugar for a where clause using operators
>>>>> which the language does not have yet - but obviously we have the code
>>>>> for...).
>>>>>
>>>>> If we are going to bike-shed over syntax - can we do so over the use of
>>>>> 'filter' itself. I don't know why but I have a complete mental block
>>>>> about it - regardless of how many times I use it or read it - I always
>>>>> have to 'double-think' to work out what form to use - is that just me?
>>>>>
>>>>> filter <things> of X with Y
>>>>> filter <things> of X without Y
>>>>>
>>>>> I couldn't tell you just by looking *what* they actually do. I'm not
>>>>> sure why but I think the verb is actually wrong - in all cases you have
>>>>> a set of things and you are either keeping an element, or removing an
>>>>> element... So I wonder if:
>>>>>
>>>>> keep <things> of X where Y
>>>>> discard <things> of X where Y
>>>>>
>>>>> (I'm not particularly attached to keep/discard - but it does need to be
>>>>> a pair of 'true' antonyms which don't intersect with any other 'core'
>>>>> pairs of such things we have).
>>>>>
>>>>> Might be more appropriate?
>>>>>
>>>>> Of course, maybe it is just 'with' / 'without' are inappropriate, and
>>>>> 'where' might actually help me retrain my mind to see with/without as
>>>>> the sugar they truly are.
>>>>>
>>>>> Anyway, thought it worth throwing out there to see what people think?
>>>>>
>>>>> Warmest Regards,
>>>>>
>>>>> Mark.
>>>>>
>>>>> --
>>>>> Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
>>>>> LiveCode: Everyone can create apps
>>>>>
>>>>> _______________________________________________
>>>>> use-livecode mailing list
>>>>> [hidden email]
>>>>> Please visit this url to subscribe, unsubscribe and manage your
>>>>> subscription preferences:
>>>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>>> _______________________________________________
>>>> use-livecode mailing list
>>>> [hidden email]
>>>> Please visit this url to subscribe, unsubscribe and manage your
>>>> subscription preferences:
>>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> use-livecode mailing list
>>> [hidden email]
>>> Please visit this url to subscribe, unsubscribe and manage your
>>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>> _______________________________________________
>> use-livecode mailing list
>> [hidden email]
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode




_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
1234567