Order dependency and builtins (Re: FW: how to go from a list of lists to a list of first elements)

Here's an (potentially very naive) idea:

some time ago, we discussed about the constraint we may impose on 
builtins, regarding which arguments must be bound prior to "executing" 
the builtin ("inputs"), and which arguments can be bound by the builtin 
itself ("outputs"). It was suggested that ouputs should always appear in 
the object position of the builtin.

If this was promoted as a hard rule, wouldn't it be possible to 
statically determine in which order to execute the builtins in a rule's 
body? (and possibly to detect cycles and fail early)?

I think I would like this much more than relying on the order in which 
triples are written...

   pa

On 17/01/2022 15:10, Jos De Roo wrote:
> Take another simple example 
> http://ppr.cs.dal.ca:3002/n3/editor/s/JJrM9yeb

>
> {?S log:equalTo :s. {:s :p :o} log:includes {?S :p :o}} => {:test1 
> :result true}.
> {{:s :p :o} log:includes {?S :p :o}. ?S log:equalTo :s} => {:test2 
> :result true}.
>
> For Cwm the order matters as it only gives
> :test2 :result true .
> for EYE the order does not matter and it gives
>
> :test1 :result true. :test2 :result true.
>
> There are examples where the order of built-ins really matters for EYE
> and I am currently inclined to let it be like that.
>
> Jos
>
> -- https://josd.github.io

> <https://josd.github.io>
>
>
> On Tue, Jan 11, 2022 at 7:35 PM William Van Woensel 
> <william.vanwoensel@gmail.com> wrote:
>
>     For instance, an example where the simple clause re-ordering
>     currently doesn’t work (as both builtin statements would be biased
>     to the end of the clause, their original ordering would be kept):
>
>     @prefix list: <http://www.w3.org/2000/10/swap/list#> .
>
>     @prefix log: <http://www.w3.org/2000/10/swap/log#> .
>
>     @prefix : <collectallin4.n3#> .
>
>     # won’t work (and will generate warnings for jen3, since the
>     list:member builtin would have a mismatched domain, since
>     “?members” isn’t bound):
>
>     {?l a :ConstantList .
>
>     (?b { ?members list:member ?m . ?m :constant ?b } ?booleans )
>     log:collectAllIn _:x .
>
>     (?m { ?l list:member ?m . ?m :constant true } ?members)
>     log:collectAllIn _:x .
>
>     } => { :test2 a ?members , ?booleans } .
>
>     # will work
>
>     {?l a :ConstantList .
>
>     (?m { ?l list:member ?m . ?m :constant true } ?members)
>     log:collectAllIn _:x .
>
>     (?b { ?members list:member ?m . ?m :constant ?b } ?booleans )
>     log:collectAllIn _:x .
>
>     } => { :test2 a ?members , ?booleans } .
>
>     (the internal “?m” variable in the where clause isn’t exposed to
>     the outside, so that one is not a problem..)
>
>     Although I can see solutions for this particular case that would
>     require some more introspection ..
>
>     William
>
>     *From: *William Van Woensel <william.vanwoensel@gmail.com>
>     *Date: *Tuesday, January 11, 2022 at 2:15 PM
>     *To: *Doerthe Arndt <doerthe.arndt@tu-dresden.de>
>     *Cc: *public-n3-dev@w3.org <public-n3-dev@w3.org>
>     *Subject: *Re: how to go from a list of lists to a list of first
>     elements
>
>     Hi Doerthe,
>
>     The built-ins log:collectAllIn and e:findall are order dependent,
>     i.e. it depends on the order of the triples in the premise of a
>     rule whether a variable is considered as local for the built-in or
>     whether it is bound by its context. A simple example would be the
>     following: http://ppr.cs.dal.ca:3002/n3/editor/s/6XTgh8ru

>     <http://ppr.cs.dal.ca:3002/n3/editor/s/FufmKC1w>
>
>     Yes, I found this problem quite early on and tried solving it
>     using a clause re-ordering
>
>     We came up with the idea that locally scoped variables (like the
>     ?task in the example) should be explicitly declared. Now, Jos
>     solved that in his implementation by using the ?select-part
>     (remember the structure ?SCOPE e:findall (?SELECT ?WHERE
>     ?ANSWER).) can be used for that declaration.
>
>     Yes I thought I was missing a step or two in that discussion :-)
>     Still, this is very unclear to me. What what would happen in this
>     case:
>
>     { ?x a :task.
>
>      ((?task ?u)  {?x :subTask ?task. ?x :marked ?u} ?ys)
>     log:collectAllIn ?Scope.
>
>      ?u log:equalTo true.
>
>     }
>
>     => { ?x :list1 ?ys }.
>
>     Would these two “?u”s simply not co-refer, would some variable
>     re-naming take place, would an error be thrown, ..?
>
>     How about this:
>
>     { ?x a :task.
>
>      (?task {?x :subTask ?task. ?x :marked ?u} ?ys) log:collectAllIn
>     ?Scope.
>
>     }
>
>     => { ?x :list1 ?ys }.
>
>     Would an error be thrown since “?u” is not grounded? Would it be
>     fine if a blank node is used?
>
>     In general I dislike how these solutions are putting the onus on
>     the N3 author to solve the problem for us. Solving this for all
>     cases with an internal rule re-ordering may be impossible (as I
>     myself tried to point out before) but I vastly prefer it at this
>     point.
>
>     Here, it depends on the outcome of our current discussion about
>     the semantics (do we have two different kinds variables or just
>     one) whether that is the case or not.
>
>     As I mentioned before, I found this “mechanism” (i.e., creating
>     rules by composing the antecedent from multiple graphs) to be very
>     useful to modularize code – see here
>     <http://ppr.cs.dal.ca:3002/n3/editor/s/RW8UEsk1> for a simplified
>     example (it doesn’t work in eye, currently).
>
>     Regards,
>
>     William
>
>     *From: *Doerthe Arndt <doerthe.arndt@tu-dresden.de>
>     *Date: *Tuesday, January 11, 2022 at 10:46 AM
>     *To: *Doerthe Arndt <doerthe_arndt@yahoo.de>
>     *Cc: *public-n3-dev@w3.org <public-n3-dev@w3.org>
>     *Subject: *Re: how to go from a list of lists to a list of first
>     elements
>
>     Hi William,
>
>     I will answer your two questions.
>
>     First about yesterday’s discussion (just a summary since Jos
>     already answered):
>
>     Original problem:
>
>     The built-ins log:collectAllIn and e:findall are order dependent,
>     i.e. it depends on the order of the triples in the premise of a
>     rule whether a variable is considered as local for the built-in or
>     whether it is bound by its context. A simple example would be the
>     following: http://ppr.cs.dal.ca:3002/n3/editor/s/6XTgh8ru

>     <http://ppr.cs.dal.ca:3002/n3/editor/s/FufmKC1w>
>
>     In the old implementation of EYE, you would have gotten
>
>     :cmp0 :list1 (:task99). :cmp1 :list1 (:task98). :cmp0 :list2
>     (:task99). :cmp1 :list2 ().
>
>
>
>
>     The important part is the second triple which is different in that
>     case.
>
>     Solution:
>
>     We came up with the idea that locally scoped variables (like the
>     ?task in the example) should be explicitly declared. Now, Jos
>     solved that in his implementation by using the ?select-part
>     (remember the structure ?SCOPE e:findall (?SELECT ?WHERE
>     ?ANSWER).) can be used for that declaration.
>
>     Concern:
>
>     While I liked the idea in general, I disliked that it means that I
>     also have to put variables in the select-pattern which I don’t use
>     for further reasoning. That would make it difficult to access the
>     result I am actually interested in (Jos gave an example below
>     which was based on your example).
>
>     Possible solution:
>
>     I thought it would help to have good built-ins to deal with the
>     lists resulting from such findall-queries with nested lists and
>     therefore Jos gave a solution.
>
>
>
>
>
>
>
>     Now, back to your original question (which is related). I guess in
>     the result you get from here
>     http://ppr.cs.dal.ca:3002/n3/editor/s/MyvdkJpa

>     <http://ppr.cs.dal.ca:3002/n3/editor/s/MyvdkJpa> which is (just to
>     be sure):
>
>
>
>
>     {?U_0 a :Mouse. ?U_0 log:equalTo :Jerry. (?U_1 {?U_1 a :Dog. ?U_1
>     :hates ?U_2} ?U_3) log:collectAllIn _:e_x_1} => {:test2 :success
>     true}.
>
>     You would like to get that ?U_0 and ?U_2 are the same variables?
>
>     Here, it depends on the outcome of our current discussion about
>     the semantics (do we have two different kinds variables or just
>     one) whether that is the case or not.
>
>     Kind regards,
>
>     Dörthe
>
>
>
>
>         ----- Weitergeleitete Nachricht -----
>
>         *Von:*Jos De Roo <josderoo@gmail.com <mailto:josderoo@gmail.com>>
>
>         *An:*William Van Woensel <william.vanwoensel@gmail.com
>         <mailto:william.vanwoensel@gmail.com>>
>
>         *CC:*public-n3-dev@w3.org
>         <mailto:public-n3-dev@w3.org><public-n3-dev@w3.org
>         <mailto:public-n3-dev@w3.org>>
>
>         *Gesendet:*Dienstag, 11. Januar 2022, 14:29:08 MEZ
>
>         *Betreff:*Re: how to go from a list of lists to a list of
>         first elements
>
>         Yes indeed William,
>         http://ppr.cs.dal.ca:3002/n3/editor/s/MyvdkJpa

>         <http://ppr.cs.dal.ca:3002/n3/editor/s/MyvdkJpa>does not work
>
>         but http://ppr.cs.dal.ca:3002/n3/editor/s/qr0in3if

>         <http://ppr.cs.dal.ca:3002/n3/editor/s/qr0in3if>works fine.
>
>         The reason is that the experimental implementation of
>         log:collectAllIn expects
>
>         that all the universals in the where-clause that are not in
>         the select-pattern
>
>         must be ground. The built-in is eventually suspended to
>         achieve this grounding.
>
>         This is also the reason that Doerthe was not happy with the
>         extended select-pattern
>
>         but the answer-list can be simplified again using list:map as
>         shown in the previous email.
>
>         Jos
>
>
>         -- https://josd.github.io <https://josd.github.io/>
>
>         On Tue, Jan 11, 2022 at 1:58 PM William Van Woensel
>         <william.vanwoensel@gmail.com
>         <mailto:william.vanwoensel@gmail.com>> wrote:
>
>             Hi Jos, Doerthe,
>
>             My confusion about this example yesterday stemmed from the
>             fact that it is unclear why “?u” is also being collected,
>             if it is not being used later on. But now I assume it is
>             simply part of the example (and not related to scoping
>             within the collectAllIn builtin, which is what I believe
>             we were talking about :-)?
>
>             On that note: as I mentioned yesterday, one could identify
>             at compile time all local variables within the where
>             clause of collectAllIn, but only barring some exceptional
>             circumstances. Such as:
>
>             http://ppr.cs.dal.ca:3002/n3/editor/s/tfsdyPr0

>             <http://ppr.cs.dal.ca:3002/n3/editor/s/tfsdyPr0>
>
>             (this “pulling in” of universal variables into rules,
>             meaning they become part of the reasoning machinery, was
>             actually a big problem in jen3..)
>
>             When compiling this example I found that the following
>             doesn’t seem to work in Eye:
>
>             http://ppr.cs.dal.ca:3002/n3/editor/s/zc2tHpTw

>             <http://ppr.cs.dal.ca:3002/n3/editor/s/zc2tHpTw>
>
>             Thoughts?
>
>             William
>
>             *From: *Jos De Roo <josderoo@gmail.com
>             <mailto:josderoo@gmail.com>>
>             *Date: *Monday, January 10, 2022 at 3:03 PM
>             *To: *public-n3-dev@w3.org
>             <mailto:public-n3-dev@w3.org><public-n3-dev@w3.org
>             <mailto:public-n3-dev@w3.org>>
>             *Subject: *how to go from a list of lists to a list of
>             first elements
>
>             This is about the question of Doerthe
>
>             [[
>
>             Question:
>
>             http://ppr.cs.dal.ca:3002/n3/editor/s/Mut5EohI

>             <http://ppr.cs.dal.ca:3002/n3/editor/s/Mut5EohI>
>
>             Would we use built-ins here?
>
>             ]]
>
>             So how to go from a list of lists to a list of first elements?
>
>             We could use list:map like is done in
>             http://ppr.cs.dal.ca:3002/n3/editor/s/xrtMG2Xc

>             <http://ppr.cs.dal.ca:3002/n3/editor/s/xrtMG2Xc>
>
>             Jos
>
>
>             -- https://josd.github.io <https://josd.github.io/>
>