syntax_error incomplete_reduction read_term

[mvolkmann]

This simple code loads fine in SWI-Prolog, but in Scryer I get error(syntax_error(incomplete_reduction),read_term/3:4).
Can you see why?

eval(Operator, L, R, Result) :-
  Operator == '+' -> Result is L + R;
  Operator == '-' -> Result is L - R;
  fail.

[mvolkmann]

The code can be simplified to the following and I still get the same error:

eval(Op, R) :- Op == '+' -> R is 1 + 2; R = 0.

[mvolkmann]

I've narrowed this down to the '+' part. Is there something wrong with using that syntax to create an atom?

[mvolkmann]

Entering atom('+'). responds with true.
Entering A = '+'. gives error(syntax_error(incomplete_reduction),read_term/3:1).
Does that make sense?

[pmoura]

Standard compliant and thus more portable (also better style):

eval(Operator, L, R, Result) :-
  (    Operator == (+) -> Result is L + R
  ;    Operator == (-) -> Result is L - R
  ;    fail
  ).

[mvolkmann]

I’m thinking this is a case where one would actually prefer to have side effects, but please tell me if you disagree. The only purpose of lim_run_scryer.pl is to read a text file (containing a Prolog term that describes an AST) and execute the code it describes as fast as possible. The global data saved using bb_put is a list of assoc tables. Those hold variable names and values. There is one for the top scope and one for each active function call. So if the top scope calls a function and that function calls another, while it runs there are three assoc tables in that list (treated as a stack). That allows each function to have its own scope for storing its local variables.

I certainly could pass state around to have a more pure solution, but I’m thinking that would make executing the code slower.

[triska]

If performance is your primary concern, then a different programming language may be a better choice for your application.

A key attraction of Prolog is that we can reason logically about our code, in the form of program fragments, generalizations and specializations, using for example the predicates from library(debug). Such program slices can also be generated automatically, and show explanations for why a predicate fails unexpectedly, or does not terminate. This works as long as we keep to the subset of Prolog where these logical properties are applicable. This subset is called the pure monotonic core of Prolog. If you leave this core, then you cannot benefit from these key attractions.

As I see it, better performance is not a good reason to leave this subset, because what good is a fast program that yields wrong results? How do you know that the predicates you have written are correct? For instance, can you easily test and reason about them?

For example, from your program, let's take only the fragment consisting of vtables_get/2 and vtables_get_/3:

vtables_get(Key, Value) :-
  bb_get(vtables, Vtables),
  vtables_get_(Vtables, Key, Value).

vtables_get_([], _, _) :- fail.
vtables_get_([H|T], Key, Value) :-
  (get_assoc(Key, H, V) ->
    Value = V;
    vtables_get_(T, Key, Value)
  ).

Now let's test the program! We start with the most general query: Which solutions are there at all? That's the most basic thing we can test:

?- vtables_get(Key, Value).
   false.

Aha! No solutions! So, we can easily replace vtables_get/2 with false/0 everywhere it occurs, right? That's a major attraction of being able to apply logical reasoning about your code. Without such properties, programming becomes trial and error, which may be preferable if one is used to it.

[mvolkmann]

Thanks again for such a detailed response!

I feel like Prolog is an ideal language to choose for parsing the syntax of another programming language (like my made up, simple language) and it is ideal for generating an abstract syntax tree (AST) describing that code. I guess it's debatable whether it is also ideal for executing the code represented by an AST and that's what I'm doing in lim_run_scryer.pl. It certainly works, but perhaps it isn't efficient enough for that use case.

Based on your feedback, I think I could do a better job by refactoring the code in lim_run_scryer.pl so most of the predicates are pure and support multiple usage modes. Then I could write a small set of non-pure predicates that use the pure predicates AND have side effects. Doing that would at least make more of my predicates testable. I'll work on that refactoring next week.

I suppose for best performance it would be nice if there was a way to perform destructive updates on an assoc, but I understand that's not the Prolog way. It would be nice to avoid the situation where any time I need to store a variable as a key/value pair in one of the assoc instances in the vtables list, I have to make a new copy of the assoc AND make a new copy of the list that holds those.

[triska]

If you want to learn Prolog, I highly recommend to keep to its pure monotonic core. Think about efficiency only if you run into a case that currently is not efficient enough. In such cases, the Prolog system itself should be improved first and foremost, so that all similar programs benefit from it. The point is to implement Scryer in such a way that Prolog code is efficiently executed. This can only happen if actual Prolog code is encountered in practice. Such code will not be encountered if everyone starts working around hypothetical inefficiencies before even encountering them, so that they can actually be addressed in Scryer itself.

From what you write in the last paragraph, my impression is that you are currently working with completely wrong assumptions about how Prolog executes programs and performs such updates. A key attraction of using association lists as implemented by library(assoc) is that you can add and remove entries in time proportional to the logarithm of the number of entries. This is efficient enough in a great number of cases that arise in practice, even if you have to manage tens or hundreds of thousands of entries, and it follows in particular that "a new copy" is not created when updating or adding an entry, since copying the entire list would incur overhead that is at least directly proportional (and hence slower than the actually guaranteed logarithmic time) to the number of entries.

I would recommend to:

1. keep to the pure monotonic core of Prolog to benefit from logical properties during testing and debugging
2. measure the time it takes, using for example time/1 from library(time)
3. if your program is not efficient enough, to isolate fragments that you would like to run faster, and then ask for improvements in Scryer Prolog so that all similar programs benefit too.

Predicates like bb_put/2 and bb_get/2 are highly specialized and do not occur in pure Prolog programs; they are non-standard (conforming) extensions that are not available in all Prolog systems, so you cannot and should not rely on their presence. They prevent logical reasoning about your code, and thus forfeit a key attraction of the language. In addition, using them counteracts and bypasses the creation of more pure Prolog code that could motivate improvements to the underlying Prolog system and thus benefit all future users of Scryer.

[mvolkmann]

Thanks again! Based on what you said about association lists, it seems likely that they use what some call "structural sharing" so that put_assoc can create a new assoc with a new key/value pair without making a complete copy of the original assoc. I will strive to stay within the pure monotonic core. Feel free to point out any instances where I am not doing that.