Semicontext notation doesn't allow pushing back a list. Intentional?

[jasagredo]

A version of the rule that works as expected is as follows:

?- [user].
look_ahead(T1, T2), [T1, T2] --> [T1, T2].

?- phrase(look_ahead(X, Y), [a,b], Z).
   X = a, Y = b, Z = "ab".

however the following minor variation of the rule fails always, and to my eyes it should equivalent to the above one:

?- [user].
look_ahead(T1, T2), L --> [T1, T2], { L = [T1, T2] }.

?- phrase(look_ahead(X, Y), [a,b], Z).
   false.

Reading the DCG primer, it specifies that:

A DCG rule of the form:

Head, [T1,...,Tn] --> Body.

can be read operationally as: parse the list using Body, then prepend the terms T1, ..., Tn to the remaining list.

But it is true that it always uses an explicit list in the semicontext notation section.

I don't really understand why pushing an item that is itself a list doesn't seem to be allowed. Perhaps this is intentional or is it just a limitation on how the rule is parsed?

[jasagredo]

The DCG primer mentions that we can inspect a rule by declaring it dynamic and using listing. For the rule that works:

?- listing(good_look_ahead//2).
good_look_ahead(A,B,C,D) :-
   C=[A,B|E],
   D=[A,B|E].
   true.

which looks good. We extract A, B and we push them back into the remaining list.

However for the faulty rule, we see this:

?- listing(faulty_look_ahead//2).
faulty_look_ahead(A,B,C,D) :-
   C=[A,B|E],
   []=[A,B],
   E=F,
   D=F.
   true.

So I think I can see two problems here:

• We push nothing back into D.
• L is already unified with [].

The right explicit code (I think) should look something like:

fixed_look_ahead(A,B,C,D) :-
   C=[A,B|E],
   L=[A,B],
   append(L, E, D).
   true.

In fact I can run this with phrase and get the expected result:

?- [user].
fixed_look_ahead(A,B,C,D) :-
   C=[A,B|E],
   L=[A,B],
   append(L, E, D).

?- phrase(fixed_look_ahead(X, Y), [a,b], Z).
   X = a, Y = b, Z = "ab".

[UWN]

Semicontext has to be a list. Thus for a rule a, L --> L there should be an error at the time of preparation for execution. Scryer just lacks this error.

[jasagredo]

You mean "an explicit list" right? Because in my above example semicontext is a list.

[UWN]

It is not a list at the point in time of preparation for execution. There it is a variable and Scryer should produce an instantiation error. The formalism does not permit more flexibility.

?- [user].
A.
   error(instantiation_error,load/1). % same error expected for cases when the semicontext is a partial list