Re: How Prolog became an education nightmare (Was: 50 Years of Prolog Nonsense)

This is also a rather frustrating case,
you might run into the same problem when
you would try doing if-then-else:
?- X = (begin x=1 end; y=2; begin z=3 end).
ERROR: Syntax error: Operator priority clash
Unparsable in both SWI-Prolog and SICStus
Prolog. On the other hand using {}/1 works:
?- X = ({x=1}; y=2; {z=3}).
X = ({x=1};y=2;{z=3}).
Mild Shock schrieb:

Yes, maybe, it depends. You would
need to fill in some logic for the
block functionality, like opening
 and closing a table with variable
names. And try it as such with a larger
variety of example. Also compare whether
 it works for both SWI-Prolog and SICStus
Prolog. What one can already see for sure,
the compile is not extremly safe anymore.
 It would also accept non well formed
input. Like you can call it with unbalanced
begin end now, and the compile/1 clause
 pattern matching will not fail, and it
will start producing some code:
 ?- compile((begin x=1 end end)).
 But maybe this is a minor problem. Another
challenge is for example the Pascal if-then-else.
Basically a mixfix with 3 holes.
     if _ then _ else _
 https://www.tutorialspoint.com/pascal/pascal_if_then_else_statement.htm
 Just like in the begin end case, where
we can provide non-well formed input
like (begin x=1 end end). Ordinary
 Prolog operators will again not provide
the safety and versatility for writing rules.
 Julio Di Egidio schrieb:

This seems to do the trick:
>
```
% SWI-Prolog 9.2.7
>
:- op(1100, fy, begin).
:- op(1100, yf, end).
>
compile((begin XEnd)) --> compile(XEnd).
compile((X end)) --> compile(X).
compile((X;Y)) --> compile(X), compile(Y).
compile((V=E)) --> [load(E),store(V)].
>
compile_t(X, L) :-
     X = (
         begin
             x = 1;
             begin
                 y = 2
             end
         end
     ),
     compile(X, L, []).
```
>
```
?- compile_t(X, L).
X = (begin x=1;begin y=2 end end),
L = [load(1),store(x),load(2),store(y)].
```
>
-Julio
>