Question

I am trying to use erlog for some testing stuff (See this repo: https://github.com/zkessin/erl_cache/tree/master/test) and I am getting something strange.

I am basically setting and clearing values in the prolog database and something weird is happening, when I try to get a value that is unset model(\"key\", Value). in prolog from the erlang command line I am getting a fail, which is I think correct, but for some reason when I am doing this from inside a test with proper I am getting back [{'Value', {0}}] and I am unsure where that 0 is being generated.

Was it helpful?

Solution

Yes, erlog is defined so that if you try to get a clause that doesn't exist it fails, even if the predicate is not defined at all. So if you do not_in_the_db(foo, Bar). it will always fails, both if there is no matching clause or no not_in_the_db/2 predicate defined at all. Erlog doesn't differentiate between dynamic declared predicates and static ones, though it probably should.

The second case when you call it from inside a test is how erlog represents variables internally. If you make a call with erlog:prove that succeeds you get back {succed,VarBindings} where VarBindings is a list of {VarName,Binding} for each variable in the goal. So in your case for a goal model("foo", Value) you will always get back a value for Value even if it has not been bound or just bound to another unbound variable.

This is where the internal representation comes in. In erlog a variable is represented by a tuple {Name} where the name is an integer, for example {45} and {139}. When you build a goal to prove variables in the goal have the same structure, the difference being you can use the variable Name in the tuple. It will be converted to the internal representation with a number in the interpreter. So when you send over the string model("foo", Value) it is first parsed to the internal representation {model,"foo",{Name}} and then sent to the interpreter. Apparently here the goal succeeds but Value is unbound so the value returned is a variable, the internal representation of a variable, in this case {0}.

This is why I was a little sceptical about your patch to allow a string as a goal, you lose the internal representation in the goal but get it back in the values. You could always convert the variable values back to a printed representation but this would be rather useless as you couldn't do anything with them except print them.

As I see it one definite use case for erlog is the fact that erlang and erlang use the same data so passing data between them is transparent. So for example it is easy to use erlog to work on ETS/Mnesia tables as no data conversions are necessary. There is a simple demo module which does this and allows you to back-track over an ETS table.

This probably needs more examples.

Robert

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top