Glen Whitney

Unfortunately the picomath proof-of-concept relies on a possible version of typed-function in which typed-functions are mutable (e.g. they can have additional signatures added to them after initial creation, without changing...

Yes, I have a new concept: in typed-function v3, we allow implementations to flag that they refer to another signature of themselves (or their entire self). I am imagining a...

OK, the new proof-of-concept [Pocomath](https://code.studioinfinity.org/glen/pocomath) is working. It does everything the original picomath did, and more. (I have not implemented the lazy-reloading of functions when a configuration option changes. I...

OK, there was one major bug in Pocomath (which I have fixed): each PocomathInstance needs to have its own typed-function instance (if for example no functions on Complex numbers have...

Update: after implementing all of the various possibilities for dependency/implementation notation yesterday, an idea for how it might be very nice to do occurred to me, which was encouraged and...

Update no. 2: I wasn't quite happy with the way types were being specified, so I fixed that up a bit and added the feature that signatures that use unknown...

Update no. 3: I implemented reference to specific signatures (of another function or of yourself). Most of the work revolved around the fact that Pocomath is lazy about types not...

Update no. 4: There was a remaining problem with the type system. Since all types were being put as keys in the value of the single identifier `Types`, it was...

> Good points on how to satisfy dependencies, with something like "concrete modules". The dynamic loading is indeed cool, though it can only be used in a node.js environment I...

> But, it isn't really simpler than `number: () => Math.sqrt` so I'm not sure if it is really needed. Shall we only implement something for that when the need...