Check to make sure that `call` and `eval` terms are permitted as sub-terms

[rpgoldman]

The manual suggests that this works, but I don't think I have ever seen a domain where this construct appears, so I don't know if it actually functions as advertised.

[rpgoldman]

I have looked into the history more deeply, and it's clear that call and eval terms were added before we took over this code from Dana's group at Maryland.

In prolog you have to use the special operator is in order to handle evaluable terms (e.g., X is Y + 3) -- you can't just use Y + 3.

So I'm really not sure what is the use case for call and eval terms that isn't handled by, e.g., assign. And I think having these adds wonkiness to the logical expression syntax that isn't good (as illustrated by #104).

So I am pondering simply removing them from the language. Or possibly there's something wrong with the term/expression distinction in the SHOP language.

[rpgoldman]

Looking further, I don't see where either eval or call terms (as opposed to expressions) are actually evaluated. I think this would have to happen in the unifier, but there's no sign that it does. Maybe the whole thing about these terms is a mistake!

[rpgoldman]

@ko56 I extended your example, and it seems that eval terms are not evaluated as the manual implies:

(in-package :shop-user)

;; (defdomain tst
;;   (
;;     (:op (!mkalist)
;;       :precond
;;       (and
;;  (setof (eval (cons ?x ?y)) (and (oper ?x) (area ?y)) ?al)
;;  )
;;       :add ((op-area-spec ?al))
;;       )
;;     )
;;   )

(defdomain tst
  (
    (:op (!mkalist)
      :precond
      (and
    (setof ?z (and (oper ?x) (area ?y) (assign ?z (cons '?x '?y))) ?al)
    )
      :add ((op-area-spec ?al))
      )
    )
  )

(defdomain tst
  (
    (:op (!mkalist)
      :precond
      (and
    (setof (?x . ?y) (and (oper ?x) (area ?y)) ?al)
    )
      :add ((op-area-spec ?al))
      )
    )
  )

(defproblem check tst
  (
   (area north) (area south)  (area east)  (area west)
   (oper opA)  (oper opB)  (oper opC)
   )
  ((!mkalist))
  )

(shop-trace :operators :states)
(find-plans 'check)

(defdomain tst2
  (
   (:op (!mkalist)
        :precond (= 22 (eval (+ 1 21)))
        )
   (:- (= ?x ?x) ())))

(defdomain tst3
  (
   (:op (!mkalist)
        :precond (= 22 22)
        )
   (:- (= ?x ?x) ())))

(defproblem check2
  ()
  ((!mkalist))
)

(format t "~&This should succeed if eval terms are evaluated:~%")
(if (find-plans 'check :domain 'tst2)
    (format t "~&Unexpected success.~%")
    (format t "~&Failed as expected.~%"))

(format t "~&This should succeed to show that the problem is not the equality predicate:~%")
(if (find-plans 'check :domain 'tst3)
    (format t "~&Succeeded as expected.~%")
    (format t "~&Unexpected failure.~%"))

[rpgoldman]

@ukuter -- Do you remember anything about eval terms and call terms? AFAICT they don't really exist, although eval and call expressions do.

[ko56]

OK, so it looks like call and eval terms are not really evaluated. Given the solution to my #104 issue, I'm fine with that, and I can't foresee now a situation where such terms would be needed. So, if you want to remove them, go ahead. My only "problem" with this, as I noted in the last message of #104, paragraph 2, has to do with (my?) confusion between the SHOP3 language and 1st-order logic: 1st-order logic allows function application to a term to produce another term. Same with Prolog. So if call terms are removed from SHOP3, we have to clarify in the manual that a "term" in SHOP3 is not the same thing as a "term" in 1st-order logic or Prolog.

Lastly, as I noted in paragraph 4 of #104, there is an example in the manual that contributes to this confusion, and seems like it has been taken from actual code (!)