Python 3.

How to start Thun under i3.

Needs the filename corrected.

It must be a BytesIO.

Trying out a different dsiplay format.

Format lists properly.

Try logging just the commands.

I3 config with suggested layout.

Stack in upper left corner, log below in same width, scratch window takes up the rest.

show_stack in case you close the stack window.

Set the font on the listbox.

Remove listbox try out script.

Update view of stack at start.

Connect it up.

Inelegant but functional.

Bring in the listbox widget with drag.

You can drag items up and down to rearrange the list.

With i3 use separate windows again.

Version 0.3.0

`primrec` combinator in Prolog

Ticket #40375

primrec combinator

Ticket #40375

Put the log and scratch text in the same window.

This is a step towards Ticket #40360 without going all the way.  You can
open additional viewer windows.  They are not connected by an
Oberon-style messaging system (yet.  It would be nice to use the Tk event
system for that.)

This way the log and the main/scratch/system-menu text are conceptually
unified in the (equivelent of "desktop") base metaphor of the system.

Python is 3 now.

Add Python 3 classifiers and ignore __pycache__ dirs.

 Closes Ticket #40371 Bump version number to 0.3.0

Rebuild docs with Python 3 and Sphinx  3.0.2.

Indent with tabs.

Trace command.

Don't print trace by default, instead a new `trace` combinator wirks like `i` and prints a trace.

Rename primrec to tailrec.

Fixes #38237 Sort out stack/unstack/enstacken/disenstacken

Switch the names of unstack and disenstacken.

Part of Ticket #38237

Still need to update the docs.

Make it easy to install the tools to build the docs.

Minor cleanup.

Some comments in gui.main.

Finally remove all mentions of the old polytypes module.

It was merged with types long ago.

Fixes #40358 Help output could be better.

For now.  Add a header and footer.  Later on when I have per-function docs
it can look those up and print them (or open a viewer in the GUI.)

Minor docs update.

Fixes #40345 automate publication of docs

With the help of a little tar script on the server and rsync.

Don't automodule non-existent joy.utils.polytypes module.

Make all the docs.

Rebuilt some sphinx docs.

Fixes: #38238 rename pushback to concat.

Depend on dulwich and future.

Sort the definitions in the library.

Rebuilt some docs.  Minor edits.

Somehow swoncat fell through the cracks.

Minor edits.

Switch to tabs for indentation.

Instead of a mix of 2- and 4-space tabs just use actual tabs.  ;-P

Fixes: #40354 Don't hardcode my own name and email as autosave committer.

Fixes: #40355 Lookup bytes no good.

Pickle protocol 2.

Dulwich expects bytes not str.

Fixes #40353 TypeError: must be str or None, not bytes

Fixes #40352 write() argument must be str, not bytes

Make sure joy.gui.main.__doc__ is at the top of the module.

Remove `__next__`.

AttributeError: 'itertools.count' object has no attribute '__next__'

Open stack pickle file in binary mode.

read text from REPL, don't eval

PEP 518

Fake brutal_hackery on Py3.

Because I'm not about to try to figure it out tonight.

futurize stage2 vui

futurize stage2 gui

futurize stage2 core

futurize stage2 core

futurize stage1 vui

futurize stage1 gui

futurize stage1 core

Fixes #38239  rename parameter of stack.pick()

Ignore build and virtual env ("venv").

Better instuctions for running docs notebooks.

Hacked up the Prolog compiler code.

Delete a pyc file.

Crap, and stuff.

Shortcircuit Boolean combinators.

Some comments.

Minor edits.

Minor edits.

Remove unused predicates appears_only_once/2 and  reg_used_once/2.

Freeing registers before using them is simpler.

https://todo.sr.ht/~sforman/thun-der/3

Partial reduction for combinator rule works after all.

It just looked weird to me and I didn't think it through.
Once I checked it I realized it was okay.

Uncovered and fixed a subtle bug in free_reg//3.

non_alloc/1 for words that don't change the ref count of registers and can be delegated to their semantic relation.

Cons.  I should research Lisp compilers...

I think I should emit high-level code and reduce it to actual
machine code later under whatever model (cons cell heap, etc.)

Add assoc to kinda sorta track the values in the registers.

But it doesn't update e.g. if you add two numbers, the value int(N) stays the same.

It could be modified to track the value as it computes?  But then why keep them in registers at all? Sometimes a value must arrive at runtime, eh?

swap, pop, and +

compiling is tricky

dup, add_ref/3.

THread through a context to track registers.

It seems to work to allocate and free registers with a kind of reference counting
by membership in an auxilliary list.

Sort of compile '+'.

Move immediate to register for int literal.

blep.

A start on machine code generation.

Just the initial messing around...

Fix a bug in step.

You think it would be easy to find all the places where the type tags are needed.

docs, formatter

Fix a bug in rest.

It didn't tag the tail list as a list.

Also, spell out bool for true cases.

Minor cleanup.

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.)

Experiments with partial reduction are very promising.

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.

Partial reduction of thun/3 in the thun/4 relation.

It mostly works.

Map combinator works with types.

Remove '==' from definitions.  (Bools)

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.

Definition for 'not' in terms of 'branch'.

Proper types, checking, inference.

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.

Don't assert defs twice.

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.

Change back to CLP(FD) semantics.

Minor changes to parser to make it less logical but a little firmer.
(E.g. ints can't be backtracked into becoming symbols!)

Docs and minor cleanup to the grammar.