9 ms·

> I didn't yet found way to seamlessly integrate it into other apps (I know that FFI is an option, but it doesn't convince me as production ready). There is in

by maweki 3y ago

> I didn't yet found way to seamlessly integrate it into other apps (I know that FFI is an option, but it doesn't convince me as production ready). There is indeed an issue with side-effects that doesn't work well with the backtracking semantics. And I am not sure there's a good solution for it. Other LP languages, like Curry, just forbid side-effects under nondeterminism and you have to collect and handle them using an implementation of effect-handlers if they aren't at the top level. That's a quite restrictive solution that needs a lot of discipline, a good architecture, and framework support. But Prolog, doing side-effects whenever, wherever such a side-effect-entailing predicate is encountered as a proof goal doesn't work either and you're bound to make your life very difficult. Even if you are careful, the code that you produce, just looks like imperative code. So nothing really gained here from using Prolog. I'm still looking/researching about solutions inbetween. Without too too much success.

tannhaeuser 3y ago
Maybe you can review Quantum Prolog's optional reification of the regular Prolog database in order to be able to backtrack over assert/retract and other destructive predicates to represent actions in eg. robotic planning. Works basically like a call/1 variant where the Prolog database to evaluate against is specified as argument rather than assumed as implicit global default, with the database a freely manipulatable list term of facts or even rules. See [1]. [1]: https://quantumprolog.sgml.io/container-planning-demo/part2.html https://quantumprolog.sgml.io/container-planning-demo/part2....
- maweki 3y ago
  That's a nice idea and it kind of works with the internal database. But in terms of FFI or other interactivity, you can't un-read bytes from an input stream or un-write to another process. That makes interoperability inherently imperative. My use case is, that you usually wouldn't un-move a robot. You want to re-plan from the current position, if an obstacle comes up. You sure as hell don't want to backtrack into an alternate plan from your original starting position.
  - YeGoblynQueenne 3y ago
    >> My use case is, that you usually wouldn't un-move a robot. You want to re-plan from the current position, if an obstacle comes up. You sure as hell don't want to backtrack into an alternate plan from your original starting position. That's right, but I think if you backtracked that far, the planning should simply fail. Are we working on something similar? I'm using Inductive Logic Programming to learn robot plans. I don't know too much about planning but I reckon what we're learning are generalised plans (with an option to make them as specialised or general as needed). The project I'm on has started only this June so I'm not yet at the point where there's need to change a plan, but I've done some thinking about it. I might be over-optimistic, but I think it's a matter of putting plans on a stack and allowing them to be carried out in LIFO order. Then, if the original plan (the first to be put on the stack) doesn't work anymore, you just backtrack to make another plan from the current position, after checking the current state of the world. OK, I don't know if that makes any sense to you. Does it?
    - maweki 3y ago
      > Are we working on something similar? It's not the first time us two have this kind of discussion. > Then, if the original plan (the first to be put on the stack) doesn't work anymore, you just backtrack to make another plan from the current position, after checking the current state of the world. Sure. That's the replanning. But actually you could backtrack into a plan you've already got that has the same prefix as the plan you've already chosen. Presumably a different plan differs from exactly this position and avoids the obstacle that made the current plan fail at that point. You'd have to keep track of the movements you've done. But as the plans are generated lazily, both concepts ('replanning' and 'choosing one of the original plans that hasn't been "superseded by reality" yet') might actually be the same.
      - YeGoblynQueenne 3y ago
        >> It's not the first time us two have this kind of discussion. Oh, I think I remember us talking about ILP. Sorry, I didn't recognise your username. Without avatars on HN I find it hard to remember who I've interacted with. I don't think we had talked about robotics or planning though. Anyway now I'll remember you :) >> Sure. That's the replanning. But actually you could backtrack into a plan you've already got that has the same prefix as the plan you've already chosen. Presumably a different plan differs from exactly this position and avoids the obstacle that made the current plan fail at that point. You'd have to keep track of the movements you've done. But as the plans are generated lazily, both concepts ('replanning' and 'choosing one of the original plans that hasn't been "superseded by reality" yet') might actually be the same. I think I see what you mean. There's certainly a problem with backtracking all the way to the point where a plan failed only to pick up again from that point- and probably fail again. I don't think I can reason about this from first principles. I'd have to try it out and see what works and what doesn't. EDIT: I went back and found our previous discussion. Hi again.

by maweki 3y ago

tannhaeuser 3y ago

Maybe you can review Quantum Prolog's optional reification of the regular Prolog database in order to be able to backtrack over assert/retract and other destructive predicates to represent actions in eg. robotic planning. Works basically like a call/1 variant where the Prolog database to evaluate against is specified as argument rather than assumed as implicit global default, with the database a freely manipulatable list term of facts or even rules. See [1]. [1]: https://quantumprolog.sgml.io/container-planning-demo/part2.html https://quantumprolog.sgml.io/container-planning-demo/part2....

maweki 3y ago
That's a nice idea and it kind of works with the internal database. But in terms of FFI or other interactivity, you can't un-read bytes from an input stream or un-write to another process. That makes interoperability inherently imperative. My use case is, that you usually wouldn't un-move a robot. You want to re-plan from the current position, if an obstacle comes up. You sure as hell don't want to backtrack into an alternate plan from your original starting position.
- YeGoblynQueenne 3y ago
  >> My use case is, that you usually wouldn't un-move a robot. You want to re-plan from the current position, if an obstacle comes up. You sure as hell don't want to backtrack into an alternate plan from your original starting position. That's right, but I think if you backtracked that far, the planning should simply fail. Are we working on something similar? I'm using Inductive Logic Programming to learn robot plans. I don't know too much about planning but I reckon what we're learning are generalised plans (with an option to make them as specialised or general as needed). The project I'm on has started only this June so I'm not yet at the point where there's need to change a plan, but I've done some thinking about it. I might be over-optimistic, but I think it's a matter of putting plans on a stack and allowing them to be carried out in LIFO order. Then, if the original plan (the first to be put on the stack) doesn't work anymore, you just backtrack to make another plan from the current position, after checking the current state of the world. OK, I don't know if that makes any sense to you. Does it?
  - maweki 3y ago
    > Are we working on something similar? It's not the first time us two have this kind of discussion. > Then, if the original plan (the first to be put on the stack) doesn't work anymore, you just backtrack to make another plan from the current position, after checking the current state of the world. Sure. That's the replanning. But actually you could backtrack into a plan you've already got that has the same prefix as the plan you've already chosen. Presumably a different plan differs from exactly this position and avoids the obstacle that made the current plan fail at that point. You'd have to keep track of the movements you've done. But as the plans are generated lazily, both concepts ('replanning' and 'choosing one of the original plans that hasn't been "superseded by reality" yet') might actually be the same.
    - YeGoblynQueenne 3y ago
      >> It's not the first time us two have this kind of discussion. Oh, I think I remember us talking about ILP. Sorry, I didn't recognise your username. Without avatars on HN I find it hard to remember who I've interacted with. I don't think we had talked about robotics or planning though. Anyway now I'll remember you :) >> Sure. That's the replanning. But actually you could backtrack into a plan you've already got that has the same prefix as the plan you've already chosen. Presumably a different plan differs from exactly this position and avoids the obstacle that made the current plan fail at that point. You'd have to keep track of the movements you've done. But as the plans are generated lazily, both concepts ('replanning' and 'choosing one of the original plans that hasn't been "superseded by reality" yet') might actually be the same. I think I see what you mean. There's certainly a problem with backtracking all the way to the point where a plan failed only to pick up again from that point- and probably fail again. I don't think I can reason about this from first principles. I'd have to try it out and see what works and what doesn't. EDIT: I went back and found our previous discussion. Hi again.