The Newton Blog

It turns out that pattern matching on Python-style tuples requires existential types. This is the second time I encounter them, so I figured it is a good opportunity to show how they arise in practise.

I was not planning on extending the type system further before 1.0, but I ran into a problem I think warrants it. That problem is assigning an appropriate type to Python’s print function. What makes the print function difficult to analyze is that it takes an arbitrary number of arguments, and those arguments can be anything. So the type has an unknown number of unknowns!

Typing a homogeneous list is much easier in comparison, because although the number of elements is unknown, there is only one type parameter.

I am now able to compile small but useful Newton programs that exercise the full feature set to Python! This is a major breakthrough because until now there was always something that would break when you tried something more complex.

Newton will follow Python except when there is a strong reason not to. This statement contradicts something I wrote earlier, that generators will be immutable. But now I’m beginning to think I want both behaviors. I don’t mean making mutation optional, I mean two separate languages, one with mutation and one wholly without.

When I started generating Python, I only thought of it as a stepping stone towards generating machine code or C. But over time, I realized the ability to generate Python is valuable in itself, just like Typescript does for Javascript. The question is, what degree of compatibility should I aim for?

Before I start generating C, I want to be able to loop over generator expressions. Having to iterate using C-style loops would be such an anticlimax. But there is a lot of work before I get there and I want to validate the approach first.

I mentioned previously that I am targetting C but did not give a reason. Why not use LLVM instead, or go straight to machine code?

I haven’t had much time for Newton since the last blog post, but I was able to get past something I have been working on for a while recently. I can now lower match statements to decision trees.

Without generators Newton would not feel very pythonic at all, so I consider it a must-have for the first public release.

I am working on adding record types to Newton. Lets look at the syntax first, then discuss how they relate to algebraic data types and classes.