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

[Martin B. <mar...@gm...>]

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.

>  > 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.

>  > 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.

>  > 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.

>  > 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?

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.

Cheers,
-- 
Martin Bravenboer
---------------------------------------------------------------------
Department of Computer and Information Science
University of Oregon