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