I feel like I should keep the un-partially-reduced thun/4 but
you can still read it, and the reduced forms are more efficient.
(And not too much more wordy.)
Functions become clauses like these:
thun(symbol(rolldown), [], [C, A, B|D], [A, B, C|D]).
thun(symbol(rolldown), [A|B], [E, C, D|F], G) :-
thun(A, B, [C, D, E|F], G).
thun(symbol(dupd), [], [A, B|C], [A, B, B|C]).
thun(symbol(dupd), [A|B], [C, D|E], F) :-
thun(A, B, [C, D, D|E], F).
thun(symbol(over), [], [B, A|C], [A, B, A|C]).7
thun(symbol(over), [A|B], [D, C|E], F) :-
thun(A, B, [C, D, C|E], F).
Definitions become
thun(symbol(of), A, D, E) :-
append([symbol(swap), symbol(at)], A, [B|C]),
thun(B, C, D, E).
thun(symbol(pam), A, D, E) :-
append([list([symbol(i)]), symbol(map)], A, [B|C]),
thun(B, C, D, E).
thun(symbol(popd), A, D, E) :-
append([list([symbol(pop)]), symbol(dip)], A, [B|C]),
thun(B, C, D, E).
These are tail-recursive and allow for better indexing so I would expect
them to be more efficient than the originals.
Notice the difference between the original thun/4 rule for definitions
and this other one that actually works.
thun(symbol(Def), E, Si, So) :- def(Def, Body), append(Body, E, E o), thun(Eo, Si, So).
thun(symbol(Def), E, Si, So) :- def(Def, Body), append(Body, E, [T|Eo]), thun(T, Eo, Si, So)
The latter reduces to:
thun(symbol(A), C, F, G) :-
def(A, B),
append(B, C, [D|E]),
thun(D, E, F, G).
We want something like...
thun(symbol(B), [], A, D) :- def(B, [H|C]), thun(H, C, A, D).
thun(symbol(A), [H|E0], Si, So) :-
def(A, [DH|DE]),
append(DE, [H|E0], E),
thun(DH, E, Si, So).
But it's good enough. The earlier version doesn't transform into
correct code:
thun(symbol(B), D, A, A) :- def(B, C), append(C, D, []).
thun(symbol(A), C, F, G) :- def(A, B), append(B, C, [D|E]), thun(D, E, F, G).
It would probably be good to investigate what goes wrong there.)
It doesn't seem to work right for thun/4 combinator rules either. Dunno what's
up there.
I decided that the conceptual simplicity of omitting '==' is more useful
than the cosmetic value of keeping it. The defs.txt file is now just one
definition per line with the first symbol giving the name.
Also, bools are literals.
When I first translated Joy into Prolog I was so blown away by the Prolog
unification over list structures and Triska's CLP(FD) semantics for math
(both in the sense that he wrote CLP(FD) for SWI Prolog and he suggested
it for Joy-in-Prolog specifically) that I didn't realize that it wasn't
quite type inference.
It's kind of like type inference, in that lists are handled correctly and
the CLP(FD) library creates and maintains a kind of context for
constraints, which are sort-of like "dependent types" if you squint a
little. But you can still do things like 'cons' a number to a number and
get (a Prolog term) like [2|3] which is almost certainly a bug.
So I went through and added type "tags" as Prolog terms: int/1, list/1,
and symbol/1. The parser assigns them and all the primitive functions
and combinators use them (and so all the definitions do too.) With this
information Prolog can e.g. prevent attempts to add numbers and lists, and
so on.
This also allows for the thun/3 relation to be implemented a little more
efficiently (without much loss of beauty) by looking ahead one term in
the pending expression and dispatching on structural "type" in a thun/4
relation. I miss the elegance of the previous version, but this lets
Prolog index on the structural type tags that the parser produces.
(This might mess up tail recursion because now we have a loop between
thun/3 and thun/4 but we can eliminate that problem by partial reduction
on thun/3. TODO.)
Now that literals are tagged by the parser there's no need for literal/1.
Each definition is getting parsed with the name of the next one as part
of its body, then the next one fails to parse and the thing backtracks.
So each definition (but the last) gets asserted twice.
def(--,[1,-,?])
def(--,[1,-])
def(?,[dup,bool,++])
def(?,[dup,bool])
def(++,[1,+,anamorphism])
def(++,[1,+])
def(anamorphism,[[pop,[]],swap,[dip,swons],genrec,app1])
def(anamorphism,[[pop,[]],swap,[dip,swons],genrec])
def(app1,[grba,infrst,app2])
def(app1,[grba,infrst])
def(app2,[[grba,swap,grba,swap],dip,[infrst],cons,ii,app3])
def(app2,[[grba,swap,grba,swap],dip,[infrst],cons,ii])
...and so on.
(I realized that the way defs are parsed now means that each def
(but the last) is first asserted with the wrong definition expression
(it includes the symbol of the following definition at the end) and
then the parser figures out that there's another defintion following
and re-asserts the correct expression. It would be nice to fix that
but it's kind of a PITA. I used to build a list of definitions and
then assert them all at the end. For now there aren't enough defs to
justify the extra work.
As much fun as it was using ? as an operator, now that all the defs live in a text file you don't see it in the Prolog code anymore.
This way I get to use sweet sweet ASCII (except for the ? symbol in the copyright notice.)
...then the branch combinator works as intended. (Although the constraint-based stuff was also cool, it would have captured information from the comparison.)
?- joy(`[32 >] [++] [--] ifte`, Si, So).
Si = [_6598|_6600],
So = [_6598+1|_6600] ;
Si = [_6598|_6600],
So = [_6598-1|_6600] ;
false.
?- sjc(hmm, `[32 >] [++] [--] ifte`).
func(hmm, [A|B], [A+1|B]).
true ;
func(hmm, [A|B], [A-1|B]).
true ;
false.
If the expression isn't 'true' or 'false' atoms then we assume it's a comparison expression and try to check its truth value.
If this fails then it will try both branches, to allow for e.g. compilation. THis almost works, but there's a choice point or something that gets hit before it tries the false path,
?- joy(` [32 >] [++] [--] ifte`, Si, So).
Si = [_2076|_2078],
So = [_2076+1|_2078] ;
wtf? +
Si = [_2076|_2078],
So = [[+], 1, _2076|_2078] ;
Si = [_2076|_2078],
So = [_2076-1|_2078] ;
wtf? -
Si = [_2076|_2078],
So = [[-], 1, _2076|_2078] ;
wtf? branch
Si = [_2076|_2078],
So = [[branch], [++], [--], _2076>32, _2076|_2078] ;
wtf? swap
Si = [_2076|_2078],
So = [[swap, branch], [--], [++], _2076>32, _2076|_2078] ;
wtf? first
Si = [_2076|_2078],
So = [[first, [++], [--], swap, branch], [_2076>32|_2078], _2076|_2078]
etc...
I like them but then you are constrained (pun intended) to only using integers. I'll probably bring them back at some point, either as an alternate implementation or their own commands.
That eliminates all the recursive calls to thun/3 (outside of thun itself, which is tail recursive.) That means that this Joy interpreter is now fully CPS.
All state is contained in the stack and expression, nothing is hidden in the Prolog "call stack".
Simon Forman