Home » Archived » B3 » Fun with sets and patterns
| Fun with sets and patterns [message #493396] |
Sun, 25 October 2009 19:19  |
 Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
Hi,
Eike's ideas about handling things as sets triggered the idea to use a
literal query. That was easily implemented, and I thought a bit further.
Armed with just a few mechanism, it is possible to do very powerful
constructs.
1. Support Literal Query.
2. The at operator on a set performs a query when the index is a literal
query. The result is a Set that matches the query.
3. Allow regular expressions as feature selectors in queries (i.e. both
for advice and as general queries using at operator.
I implemented this to get a feel for what it looks like, and I am very
pleased. In comparison the "in" operator is really lame, and I dropped it.
Examples:
- check if a has a property b
a[~{b}].isEmpty();
- check if a has a property b with a property c
a[~{b:c}].isEmpty();
- check if a has a property that is called 'creatNNN' [sic] where NNN is
a sequence of digits, and if so, if that property has a property
'status' set to true - if so, return the set consisting of all ancestors
of this node's parent - then invoke a function that prints each.
a[ ~{ ~/^creat[0-9]+/g[status==true]:..:**}.forEach(function(x){
print x; });
Imagine doing this with loops and if/then/else.
I see this as very useful when working with a model, a file system
(select on name, time, type, etc), or an XML document that must be
parsed as part of a build.
regards
- henrik
|
|
|
| Re: Fun with sets and patterns [message #493404 is a reply to message #493396] |
Mon, 26 October 2009 00:57  |
|
Hi Henrik,
Powerful indeed but not very readable. Can we get both?
On 10/25/2009 08:19 PM, Henrik Lindberg wrote:
> Hi,
> Eike's ideas about handling things as sets triggered the idea to use a
> literal query. That was easily implemented, and I thought a bit further.
>
> Armed with just a few mechanism, it is possible to do very powerful
> constructs.
>
> 1. Support Literal Query.
>
> 2. The at operator on a set performs a query when the index is a literal
> query. The result is a Set that matches the query.
>
I think we should make that with a select. I.e. instead of:
a[query]
do it like this (using smalltalk terms):
a.select(query)
a.select(function(x) { // a boolean condition })
a.reject(query)
a.reject(function(x) { // a boolean condition })
a.detect(query)
a.detect(function(x) { // a boolean condition })
a.collect(function(x) { // a function returning an element to collect })
I'm opposed to using the [] operator because in my view it is supposed to remove a dimension. Getting a set out of a set
doesn't do that. To me, using [] means "give me one element from the operand" no matter what. I have a hard time
accepting that it would return subset.
> 3. Allow regular expressions as feature selectors in queries (i.e. both
> for advice and as general queries using at operator.
>
> I implemented this to get a feel for what it looks like, and I am very
> pleased. In comparison the "in" operator is really lame, and I dropped it.
>
> Examples:
> - check if a has a property b
>
> a[~{b}].isEmpty();
>
Shows the power, but is also somewhat complex way of expressing:
a.detect("b");
> - check if a has a property b with a property c
>
> a[~{b:c}].isEmpty();
>
Would it be possible to use the '?' for a query instead of '~{}' ? I liked the idea of having '~' dedicated to regexps.
Your expression could then be written:
a.detect(?b:c);
> - check if a has a property that is called 'creatNNN' [sic] where NNN is
> a sequence of digits, and if so, if that property has a property
> 'status' set to true - if so, return the set consisting of all ancestors
> of this node's parent - then invoke a function that prints each.
>
> a[ ~{ ~/^creat[0-9]+/g[status==true]:..:**}.forEach(function(x){ print
> x; });
>
Powerful indeed. Alternative syntax:
a.select(?~/^creat[0-9]+/g[status==true]:..:**).do(function( x) { print x; })
- thomas
|
|
| |
| Re: Fun with sets and patterns [message #493444 is a reply to message #493423] |
Mon, 26 October 2009 09:44 |
|
On 10/26/2009 09:29 AM, Henrik Lindberg wrote:
> With your solution all classes must support the set operations. You need
> a wrapper. An operator is needed IMO.
Yes, sorry if I was unclear on that point. I meant that we introduce select/reject/collect/detect as keywords.
> I obviously do not have an issue
> with returning a set using at-query.
>
I'm fairly convinced that most people would think that applying an [] on a container of some sort returns ONE element
from that container. I've never seen an exception to that rule. Have you?
In essence, you say that depending on the type of x in the expression y.opAt(x), you change the return type of the
method from being a element of y (i.e. one dimension less) to be a subset of elements of y. We should use another
method/operator for that. Using [] is just confusing.
>>> a[~{b}].isEmpty();
>>>
>> Shows the power, but is also somewhat complex way of expressing:
>>
>> a.detect("b");
>>
> Same issue again. All asses must support the methods. Needs to be an
> operator.
>
Yes. But let's use a different operator. The syntax could be even simpler:
a detect "b"
Besides increased readability, and less confusion about what [] does, you are also free to introduce other meaningful
operators, i.e. select/reject/collect.
>>> - check if a has a property b with a property c
>>>
>>> a[~{b:c}].isEmpty();
>>>
>>
>> Would it be possible to use the '?' for a query instead of '~{}' ? I
>> liked the idea of having '~' dedicated to regexps.
>
> No. Ambiguous, and it needs to be delimited.
>
How about: query {b:c} then? Example above could then be written:
a detect query {b:c}
which rimes well with for instance:
a detect function(x) { b.c / x > 3 }
More power and improved readability.
- thomas
|
|
|
| Re: Fun with sets and patterns [message #493459 is a reply to message #493423] |
Mon, 26 October 2009 11:19 |
Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
(killing time on an airplane using iPhone news client, so pardon
typos...)
The reason I like the at operator instead if an infix operator is that
it is very likely that you want to invoke further methods on the result
as a set e.g.
X[~{q}].collect(...)
With infix op, parentheses are needed
(X ?? ~{q}).collect(...)
Unless ?? Has higher precedence, but it would be odd looking
X ?? ~{q}.collect(...)
So a postfix op like [] is better. It could be specialized, but
specialisation must be right of opening [ however, for almost all chars
since too many expressions would otherwise depend on use of whitespace.
X[|~{q}]
However @ can be placed before the []. it can be seen as a postfix op
that makes the lhs into a feature set. Using [] to index in this feature
set is perhaps easier to grasp ;)
a =X@; a[~{q}]. Is equivalent to
X@[~{q}]
and it would only be feature set that would know about queries. A
literal array, map etc would look at the query as any other literal key.
This is an impovement as logic would otherwise need to detect the
special case of at-query.
I like this solution best. But I have more alternatives...
It may be possible to use | as delimiters, as in
X|~{q}|
as this operation has higher precedence than binary infix 'or', but I
have a strong feeling this is hard to parse, and it requires correct use
of spaces to not clash with bit | or logical ||.
Yet another alternative is to turn it around, and invoke a select method
on the query literal.
~{q}.selectFrom(X)
Henrik Lindberg <henrik.lindberg@cloudsmith.com> wrote:
> Thomas Hallgren <thomas@tada.se> wrote:
> > I think we should make that with a select. I.e. instead of:
> >
> > a[query]
> >
> > do it like this (using smalltalk terms):
> >
> > a.select(query)
> > a.select(function(x) { // a boolean condition })
> > a.reject(query)
> > a.reject(function(x) { // a boolean condition })
> > a.detect(query)
> > a.detect(function(x) { // a boolean condition })
> > a.collect(function(x) { // a function returning an element to
> > collect })
> >
> > I'm opposed to using the [] operator because in my view it is
> > supposed
> > to remove a dimension. Getting a set out of a set
> > doesn't do that. To me, using [] means "give me one element from the
> > operand" no matter what. I have a hard time
> > accepting that it would return subset.
> >
> With your solution all classes must support the set operations. You
> need
> a wrapper. An operator is needed IMO. I obviously do not have an issue
> with returning a set using at-query.
>
> > > a[~{b}].isEmpty();
> > >
> > Shows the power, but is also somewhat complex way of expressing:
> >
> > a.detect("b");
> >
> Same issue again. All asses must support the methods. Needs to be an
> operator.
>
> > > - check if a has a property b with a property c
> > >
> > > a[~{b:c}].isEmpty();
> > >
> >
> > Would it be possible to use the '?' for a query instead of '~{}' ? I
> > liked the idea of having '~' dedicated to regexps.
>
I see it as ~ means literal pattern, and the next char tells if it is a
regexp, / / or query {}.
--
- henrik
|
|
|
| Re: Fun with sets and patterns [message #493460 is a reply to message #493444] |
Mon, 26 October 2009 11:22 |
Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
Confusion, the at operator returns one object at all times - a feature
set if it is the result of a query.
Will respond later when on computer, takes too long on iPhone to tap all
special chars...
Thomas Hallgren <thomas@tada.se> wrote:
> On 10/26/2009 09:29 AM, Henrik Lindberg wrote:
>
> > With your solution all classes must support the set operations. You
> need
> > a wrapper. An operator is needed IMO.
>
> Yes, sorry if I was unclear on that point. I meant that we introduce
> select/reject/collect/detect as keywords.
>
> > I obviously do not have an issue
> > with returning a set using at-query.
> >
> I'm fairly convinced that most people would think that applying an []
> on a container of some sort returns ONE element
> from that container. I've never seen an exception to that rule. Have
> you?
>
> In essence, you say that depending on the type of x in the expression
> y.opAt(x), you change the return type of the
> method from being a element of y (i.e. one dimension less) to be a
> subset of elements of y. We should use another
> method/operator for that. Using [] is just confusing.
>
> >>> a[~{b}].isEmpty();
> >>>
> >> Shows the power, but is also somewhat complex way of expressing:
> >>
> >> a.detect("b");
> >>
> > Same issue again. All asses must support the methods. Needs to be
> an
> > operator.
> >
> Yes. But let's use a different operator. The syntax could be even
> simpler:
>
> a detect "b"
>
> Besides increased readability, and less confusion about what [] does,
> you are also free to introduce other meaningful
> operators, i.e. select/reject/collect.
>
> >>> - check if a has a property b with a property c
> >>>
> >>> a[~{b:c}].isEmpty();
> >>>
> >>
> >> Would it be possible to use the '?' for a query instead of '~{}' ?
> I
> >> liked the idea of having '~' dedicated to regexps.
> >
> > No. Ambiguous, and it needs to be delimited.
> >
> How about: query {b:c} then? Example above could then be written:
>
> a detect query {b:c}
>
> which rimes well with for instance:
>
> a detect function(x) { b.c / x > 3 }
>
> More power and improved readability.
>
> - thomas
--
- henrik
|
|
| | |
| Re: Fun with sets and patterns [message #589582 is a reply to message #493396] |
Mon, 26 October 2009 00:57 |
|
Hi Henrik,
Powerful indeed but not very readable. Can we get both?
On 10/25/2009 08:19 PM, Henrik Lindberg wrote:
> Hi,
> Eike's ideas about handling things as sets triggered the idea to use a
> literal query. That was easily implemented, and I thought a bit further.
>
> Armed with just a few mechanism, it is possible to do very powerful
> constructs.
>
> 1. Support Literal Query.
>
> 2. The at operator on a set performs a query when the index is a literal
> query. The result is a Set that matches the query.
>
I think we should make that with a select. I.e. instead of:
a[query]
do it like this (using smalltalk terms):
a.select(query)
a.select(function(x) { // a boolean condition })
a.reject(query)
a.reject(function(x) { // a boolean condition })
a.detect(query)
a.detect(function(x) { // a boolean condition })
a.collect(function(x) { // a function returning an element to collect })
I'm opposed to using the [] operator because in my view it is supposed to remove a dimension. Getting a set out of a set
doesn't do that. To me, using [] means "give me one element from the operand" no matter what. I have a hard time
accepting that it would return subset.
> 3. Allow regular expressions as feature selectors in queries (i.e. both
> for advice and as general queries using at operator.
>
> I implemented this to get a feel for what it looks like, and I am very
> pleased. In comparison the "in" operator is really lame, and I dropped it.
>
> Examples:
> - check if a has a property b
>
> a[~{b}].isEmpty();
>
Shows the power, but is also somewhat complex way of expressing:
a.detect("b");
> - check if a has a property b with a property c
>
> a[~{b:c}].isEmpty();
>
Would it be possible to use the '?' for a query instead of '~{}' ? I liked the idea of having '~' dedicated to regexps.
Your expression could then be written:
a.detect(?b:c);
> - check if a has a property that is called 'creatNNN' [sic] where NNN is
> a sequence of digits, and if so, if that property has a property
> 'status' set to true - if so, return the set consisting of all ancestors
> of this node's parent - then invoke a function that prints each.
>
> a[ ~{ ~/^creat[0-9]+/g[status==true]:..:**}.forEach(function(x){ print
> x; });
>
Powerful indeed. Alternative syntax:
a.select(?~/^creat[0-9]+/g[status==true]:..:**).do(function( x) { print x; })
- thomas
|
|
| |
| Re: Fun with sets and patterns [message #589599 is a reply to message #493423] |
Mon, 26 October 2009 09:44 |
|
On 10/26/2009 09:29 AM, Henrik Lindberg wrote:
> With your solution all classes must support the set operations. You need
> a wrapper. An operator is needed IMO.
Yes, sorry if I was unclear on that point. I meant that we introduce select/reject/collect/detect as keywords.
> I obviously do not have an issue
> with returning a set using at-query.
>
I'm fairly convinced that most people would think that applying an [] on a container of some sort returns ONE element
from that container. I've never seen an exception to that rule. Have you?
In essence, you say that depending on the type of x in the expression y.opAt(x), you change the return type of the
method from being a element of y (i.e. one dimension less) to be a subset of elements of y. We should use another
method/operator for that. Using [] is just confusing.
>>> a[~{b}].isEmpty();
>>>
>> Shows the power, but is also somewhat complex way of expressing:
>>
>> a.detect("b");
>>
> Same issue again. All asses must support the methods. Needs to be an
> operator.
>
Yes. But let's use a different operator. The syntax could be even simpler:
a detect "b"
Besides increased readability, and less confusion about what [] does, you are also free to introduce other meaningful
operators, i.e. select/reject/collect.
>>> - check if a has a property b with a property c
>>>
>>> a[~{b:c}].isEmpty();
>>>
>>
>> Would it be possible to use the '?' for a query instead of '~{}' ? I
>> liked the idea of having '~' dedicated to regexps.
>
> No. Ambiguous, and it needs to be delimited.
>
How about: query {b:c} then? Example above could then be written:
a detect query {b:c}
which rimes well with for instance:
a detect function(x) { b.c / x > 3 }
More power and improved readability.
- thomas
|
|
|
| Re: Fun with sets and patterns [message #589608 is a reply to message #493423] |
Mon, 26 October 2009 11:19 |
Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
(killing time on an airplane using iPhone news client, so pardon
typos...)
The reason I like the at operator instead if an infix operator is that
it is very likely that you want to invoke further methods on the result
as a set e.g.
X[~{q}].collect(...)
With infix op, parentheses are needed
(X ?? ~{q}).collect(...)
Unless ?? Has higher precedence, but it would be odd looking
X ?? ~{q}.collect(...)
So a postfix op like [] is better. It could be specialized, but
specialisation must be right of opening [ however, for almost all chars
since too many expressions would otherwise depend on use of whitespace.
X[|~{q}]
However @ can be placed before the []. it can be seen as a postfix op
that makes the lhs into a feature set. Using [] to index in this feature
set is perhaps easier to grasp ;)
a =X@; a[~{q}]. Is equivalent to
X@[~{q}]
and it would only be feature set that would know about queries. A
literal array, map etc would look at the query as any other literal key.
This is an impovement as logic would otherwise need to detect the
special case of at-query.
I like this solution best. But I have more alternatives...
It may be possible to use | as delimiters, as in
X|~{q}|
as this operation has higher precedence than binary infix 'or', but I
have a strong feeling this is hard to parse, and it requires correct use
of spaces to not clash with bit | or logical ||.
Yet another alternative is to turn it around, and invoke a select method
on the query literal.
~{q}.selectFrom(X)
Henrik Lindberg <henrik.lindberg@cloudsmith.com> wrote:
> Thomas Hallgren <thomas@tada.se> wrote:
> > I think we should make that with a select. I.e. instead of:
> >
> > a[query]
> >
> > do it like this (using smalltalk terms):
> >
> > a.select(query)
> > a.select(function(x) { // a boolean condition })
> > a.reject(query)
> > a.reject(function(x) { // a boolean condition })
> > a.detect(query)
> > a.detect(function(x) { // a boolean condition })
> > a.collect(function(x) { // a function returning an element to
> > collect })
> >
> > I'm opposed to using the [] operator because in my view it is
> > supposed
> > to remove a dimension. Getting a set out of a set
> > doesn't do that. To me, using [] means "give me one element from the
> > operand" no matter what. I have a hard time
> > accepting that it would return subset.
> >
> With your solution all classes must support the set operations. You
> need
> a wrapper. An operator is needed IMO. I obviously do not have an issue
> with returning a set using at-query.
>
> > > a[~{b}].isEmpty();
> > >
> > Shows the power, but is also somewhat complex way of expressing:
> >
> > a.detect("b");
> >
> Same issue again. All asses must support the methods. Needs to be an
> operator.
>
> > > - check if a has a property b with a property c
> > >
> > > a[~{b:c}].isEmpty();
> > >
> >
> > Would it be possible to use the '?' for a query instead of '~{}' ? I
> > liked the idea of having '~' dedicated to regexps.
>
I see it as ~ means literal pattern, and the next char tells if it is a
regexp, / / or query {}.
--
- henrik
|
|
|
| Re: Fun with sets and patterns [message #589616 is a reply to message #493444] |
Mon, 26 October 2009 11:22 |
Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
Confusion, the at operator returns one object at all times - a feature
set if it is the result of a query.
Will respond later when on computer, takes too long on iPhone to tap all
special chars...
Thomas Hallgren <thomas@tada.se> wrote:
> On 10/26/2009 09:29 AM, Henrik Lindberg wrote:
>
> > With your solution all classes must support the set operations. You
> need
> > a wrapper. An operator is needed IMO.
>
> Yes, sorry if I was unclear on that point. I meant that we introduce
> select/reject/collect/detect as keywords.
>
> > I obviously do not have an issue
> > with returning a set using at-query.
> >
> I'm fairly convinced that most people would think that applying an []
> on a container of some sort returns ONE element
> from that container. I've never seen an exception to that rule. Have
> you?
>
> In essence, you say that depending on the type of x in the expression
> y.opAt(x), you change the return type of the
> method from being a element of y (i.e. one dimension less) to be a
> subset of elements of y. We should use another
> method/operator for that. Using [] is just confusing.
>
> >>> a[~{b}].isEmpty();
> >>>
> >> Shows the power, but is also somewhat complex way of expressing:
> >>
> >> a.detect("b");
> >>
> > Same issue again. All asses must support the methods. Needs to be
> an
> > operator.
> >
> Yes. But let's use a different operator. The syntax could be even
> simpler:
>
> a detect "b"
>
> Besides increased readability, and less confusion about what [] does,
> you are also free to introduce other meaningful
> operators, i.e. select/reject/collect.
>
> >>> - check if a has a property b with a property c
> >>>
> >>> a[~{b:c}].isEmpty();
> >>>
> >>
> >> Would it be possible to use the '?' for a query instead of '~{}' ?
> I
> >> liked the idea of having '~' dedicated to regexps.
> >
> > No. Ambiguous, and it needs to be delimited.
> >
> How about: query {b:c} then? Example above could then be written:
>
> a detect query {b:c}
>
> which rimes well with for instance:
>
> a detect function(x) { b.c / x > 3 }
>
> More power and improved readability.
>
> - thomas
--
- henrik
|
|
| | |
Goto Forum:
Current Time: Thu Apr 25 13:22:10 GMT 2024
Powered by FUDForum. Page generated in 0.04021 seconds |
] 
Search
Help
Register
Login
Home
