Re: [iris-reasoner-support] IRIS: syntax patch, and a few questions

[Barry B. <bar...@st...>]

Hi Martin!

Congratulations on being the first IRIS user to use the support mailing 
list!  :)

Martin Bravenboer wrote:
> Hi Richard,
> 
> Thanks for your reply.
> 
>>  The project page is hosted on sf and there would also be
>>  some mailing list/forum stuff
> 
> Right, I checked that place, but the mailing list didn't look active
> to me. I've CC'ed the list this time. I've quoted most of the earlier
> email for the record.

It wasn't active, but I'm sure you've started the ball rolling now!

>>  > I'm using IRIS as a command-line tool that evaluates a Datalog
>>  > programs read from a file. I had a few problems with generating IRIS
>>  > Datalog facts involving string literals from the programs that I want
>>  > to analyse. I've attached an update of iris.scc (as a complete file
>>  > and a patch, if you prefer that). The fixes are:
>>  >
>>  > 1) eol optional in an eol comment (otherwise an eol comment at the end
>>  > of the file doesn't parse).
>>  >
>>  > 2) introduced long comments /* ... */
>>  >
>>  > 3) more flexible string literals: allow all characters, except for cr,
>>  > lf, ' and \. Those four characters can be escaped using \n, \r, \',
>>  > and \\. This fix is quite important for my applications.
>>
>>  I will have a closer look about the changes and write some tests, when I got the
>>  time. After a review with Barry I can apply them.
>>
>>  One question:
>>
>>  Is this really the shortest/simplest way to write this? I tried to understand
>>  it, but I couldn't get trough it:
>>
>>     long_comment = '/*' not_star* '*'+ (not_star_slash not_star* '*'+)* '/';
>>
>>  wouldn't
>>
>>     long_comment = '/*' not_star_slash* '*/';
>>
>>  do the same thing?
> 
> This definition is the common way of defining long comments in
> Java-like languages. If you check the SableCC grammar of Java, etc,
> you will see something very similar.
> 
> Your version would not allow a * and / at all in the comment. For
> example, this would reject the useful Javadoc style:
> 
> /**
>  *
>  */
> 
> I'm using these comments right now to document my rules.

Thanks for your all suggestions here. We have been planning to do 
something about these for some time, but no-one had got around to it. We 
will likely be making a new release of IRIS in the coming week or two 
and hope to incorporate most of your ideas.

>>  > I thought about supporting more character escapes (like \t), but this
>>  > is a bit more complex. I considered to unescape the string literal in
>>  > the TreeWalker, but string are used in many places. Worse, they need
>>  > to be escaped again when printed somewhere (e.g. to print results to a
>>  > file). There is no clean place to do escaping at the moment (because
>>  > strings are used in many places), so I decided that keeping the
>>  > special characters escaped would be more convenient. Using escaped
>>  > characters at run-time works fine: it doesn't matter if the special
>>  > characters are escaped or not in the runtime representation of a
>>  > string.
>>
>>  During the runtime it doesn't matter, whether they are escaped, or not, because
>>  IRIS uses the ordinary String.compare(...) or String.equals(...) methods. Imho
>>  to enable those escaped characters it would only be necessary to edit the string
>>  term handling in the tree walker and the toString() method of the string term to
>>  handle them. Or did you experience something different?
> 
> No, this is more or less the problem yeah. It doesn't matter if the
> characters are escaped or not, as long as they are *always* escaped or
> not.

We will likely go for the 'always escaped' version, i.e. "\t" in an 
input file always means "<tab>".

Further, to allow compatibility with other reasoners we will allow 
strings to be delimited with " and ', however for simplicity/consistency 
both of these characters will always need to be escaped inside a string

>>  > 1) Is there support for checking if all predicates of a set of rules
>>  > occur in a fact, or can be derived using a different rule? I just want
>>  > a simple warning if there is a typo in a predicate name. If there is
>>  > no such thing, then I can easily implement it myself, but I just
>>  > wanted to check with you first.
>>
>>  Imho there is no such possibility, at the moment.
> 
> Okay, thanks, I'll implement it myself then.

Afraid so. There is no standard 'dataloggy' way to do this.

>>  > 2) Is there something like a wildcard? Sometimes, I don't care about a
>>  > certain element of a relation, like the variable ?sometype in
>>  > "MethodSignature(?signature, ?sometype, ?simplename, ?descriptor)". Is
>>  > it possible to use something like a _ instead of having to invent a
>>  > variable name?
>>
>>  No, I know only the unique variable trick. But this could be implemented by a
>>  term, which is equal to everything (which is imho a more or less dirty hack).
> 
> Okay, thanks. It would be very useful to have a wildcard feature. An
> easier solution might be to replace wildcards with unique variable
> names?

No plans for this just yet!

> Another question: do you have any plans/ideas about an include/import
> feature for Datalog files? I'm defining variants of some datalog
> specifications, and I find myself copying sets of rules now and then.
> It would be nice if I could save these in a separate file and import
> them.

Hmmm, this in an interesting idea. Something like C style 
#include<filename> maybe?

Of course, if you do have a C compiler installed you can just use the 
pre-processor to do this kind of thing, e.g.

d1.txt
------
p(?x) :- q(?x).


d2.txt
------
#include "d1.txt"
q(1).
?- q(?x).


gcc -E -x c d2.txt | grep -v '#'
--------------------------------
p(?x) :- q(?x).
q(1).
?- q(?x).


You could also create macros and have conditional compilation, etc. 
Well, just a thought...


Thanks again for your interest.

Regards,

Barry Bishop
Senior Scientific Programmer
Semantic Technology Institute (STI)
University of Innsbruck, Austria
-----------------------------------
E-Mail: bar...@st...
Tel:    +43 512 507 96873
-----------------------------------