s(CASP) online reply 1

Help!
1

Thanks Jan this is interesting stuff.
I tried the following program from a tutorial:

opera(D) :- not home(D).
home(D):- not opera(D).
home(monday).

:-baby(D), opera(D).

baby(tuesday).

?-opera(D).

I get D ∉ [monday] but I expected D ∉ [monday],D ∉ [tuesday]

Do I need some kind of special syntax for a denial here?

2

Hi Sam, I get the correct answer, both using the scasp executable as using library(scasp). What exactly did you do with which version?

3

I was using s(CASP) web server

4

There was an issue handling global constraints there. Fixed and updated the webserver. You may need to do a SHIFT-reload to get the JavaScript and CSS updated properly.

edit: in embedded code global constraints are (for now) written as below to avoid ambiguity with directives. The web server allows for both notations.

 false :- constraint.
5

Ok! Thanks for the fast fix :slight_smile: i will keep exploring …

6

Human explanation is broken with Sam’s example:

#pred opera(D) :: 'I can be at the opera on @(D:day)'.

opera(D) :- not home(D).
home(D):- not opera(D).
home(monday).

:-baby(D), opera(D).

baby(tuesday).

> I can be at the opera on a day, because
> The global constraints hold, because

If we remove the #pred everything is fine:

> opera holds for D not monday, or tuesday, because
> The global constraints hold, because
7

Thanks. I’m working on it :slight_smile:

1 Like
8

In relation to the human output, I think the most sensible solution is the one you are already working on: to provide an intermediate (tree) representation that then can be turned into human output by a DCG,.

sCASP can then provide some default DCGs, but the user can do their own.

This will be extremely useful because:

  • multi-language support
  • human output for nested reasoning could be turned into simpler sentences depending on the particular domain
  • some negations could be turn into more reasonable human output, for example X ∉ [wednesday, thursday, and friday] could be turned into ‘Monday or Tuesday’ for some particular user for whom that is easier to process.
  • It can be used to generate visualized graphs, e.g. with graphviz dot, etc.

So all in all, I think you have the best design choice there, as usual :slight_smile:

1 Like
9

Ok. This is fixed. There is a gotcha here. Prolog variables have no name (as you undoubtedly know), so there is no way to associate the Prolog variable with the @(D:day) :frowning: The system now checks for prolog_load_context/2 using the variable_names context to work around this. The price for normal Prolog code is that you still get a singleton warning.

To make dynamic usage of #pred possible, the variables may be instantiated to atoms as below. The thing in the template must satisfy the rules for a Prolog variable. If the term contains a matching atom, this is replaced by the variable.

#pred opera('D') :: 'I can be at the opera on @(D:day)'.

For the version of s(CASP) web server this is not an issue as this doesn’t use normal Prolog file loading and the terms are read without singleton warnings enabled, after which we bind variables in #pred terms to their name.

I think this should in due time be replaced with grammar rules, something like

pred(opera(D)) -->
    [ 'I can be at the opera on ' ],
    scasp_term(D, day).

Good news is that there is now also support in there is now also s(CASP) support in SWISH. See the intro page

3 Likes