valueDiff for arrays?

Brian Milby brian at milby7.com
Sun Aug 5 11:00:05 EDT 2018


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 <use-livecode at lists.runrev.com>, 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 ~ mark at livecode.com ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode



More information about the use-livecode mailing list