Type checking e.g. sum or product.
Any type accepts complex numbers.
Lots of the math functions now just use Number rather than more specific
poly-types.
Now the UI highlights commands and numbers as you move the mouse, numbers
are blue, commands that type-check are green, commands that fail to
type-check are orange and will not be interpreted, and if there is no
stack effect information available for a command it is grey but you can
still attempt to execute it.
You can still evaluate whole expressions by selceting them and
right-inter-clicking before you release the left button, or by putting
the cursor on a line and typing ctrl-enter, which will run the whole
line. These expressions are NOT (yet) type-checked.
If type vars get into the espression you have to keep them in sync with
the unification or you can lose information.
Some combinators can put symbols on the expression, you have to convert
those to type checkers or, as a hack, just look them up and run them.
This lets definitions work(-ish), ...
It forces the identities of lits to change during relabel().
I think we still have to update() the expression to track changes in the
F function stack effect or we risk losing assoviations between type
variables in the stack effects and type variables in the pending
expression. Hrmmm.
So they can notice if they're given a stack that doesn't match what
they're expecting.
This seems to work, but I realized that type variables in the pending
expression need to be update()'d too. hmm...
I'm backfilling tests to cover the functionality that I developed
incrementally in the Jupyter notebook and nail it down with concrete
examples. No doubt I'll uncover some bugs.
I love make. (Despite not working with spaces in filenames, since that's
a dumbass thing to do anyway.) There's probably a better way to do what
I did but it works so I'm happy.
Converting the notebooks to ReST with nbconvert, then using sphinx on the
.rst files gives a pretty decent effect, except that the title levels are
off a little.
I need to look into hosting for the notebooks, maybe on MS Azure. In the
meantime, I prefer the HTML made by Sphinx to the HTML made by nbconvert
directly. It has index and cross refs and the code blocks scroll
horizontally which is crucial for wide Joy traces. And Garamond. God
bless Garamond.
For the Sphinx docs I'm going to edit the notebook ReST files by hand,
diverging from the originals.
Used Pandoc to convert the notebooks to rst format. Used 2to3 to edit
the function signatures that were causing sphinx to error out. Am I
really the only one who uses that syntax?
I had to remove the tuples from the args specs, sphinx had kittens.
I see value both in the autodoc for library.py and the library examples
Jupyter notebook (converted to ReST format) so I'm including them both.
Calling the library module autodocs the "Function Reference".
I waited too long to upload to PyPI and some other bastard snagged the name. I originally wanted to call it "Thun" as a tribute to Manfred von Thun, but I was concerned that this might seem to violate the thrid clause in the license of the original Joy code, to wit:
3. The name of the author may not be used to endorse or promote products derived from this software without specific prior written permission.
Since the author is deceased I don't know of whom to ask permission to call this project Thun, but since I am not trying to "endorse or promote" this project with his name it should be alright. In any event if anyone complains I can rename the project again.
Simon Forman