Newton is still under development. The above points are aspirational.
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.
Newton is a new language being developed. It is not ready to be released yet, but I will use this site to keep friends and interested parties up to date.
