Nominal type checker w/ higher types & generics

[BeksOmega]

Codename: Project Static

Category

• Plugins

Is your feature request related to a problem? Please describe.

Blockly's built-in type checker makes it hard to model languages which have strong static typing like C, C#, Java, Swift, Rust, etc. Currently, modeling subtyping requires connection checks to be very verbose and WET. There is also no support for generics in the current system.

Describe the solution you'd like

A nominal static type checker with support for higher types and generics. This would act as an optional replacement for Blockly's built in type checker.

Additional

Are you guys still ok with me taking on this project? If so, is this issue a good place to organize conversation?

I've been pretty excited about this project so I started work on a design document discussing how I think it should work from the perspective of someone integrating Blockly into their application. I think it would be good to get input from people on the forums about it once it's done, because this requires so many design decisions. How do you guys feel about that?

I also have a pretty good idea of how I would to go about implementing the system, but I didn't want to bog the doc down with all of those details.

All that being said, I'm still totally cool if you think someone else should take this on hehe.

[rachel-fenichel]

Yes, you should definitely work on this, and I agree about getting input from people on the forums after getting the design sorted and before starting the serious lifting on implementation. Let's use your doc for back-and-forth on the design, and then post a summary here once you're happy with the design.

[BeksOmega]

Ok, I think the doc does a pretty good job explaining what I was imagining now =) Anyone can feel free to take a look. All comments and suggestions are welcome, regardless of whether they be about the design or the doc itself :D

[Edit: Added a section on Multiple generic input checks, and a section on Constraints containing generic type names]

[BeksOmega]

Update [does Not require response]

I got really far with getting the generic bindings to "flow" between connections (see here) but I ran into a problem earlier today, so I think I'm going to have to try a different tact.

I didn't consider situations like the following:

(to be clear the above gif has the incorrect behavior)

Where the Identity block needs to get constantly updated with the info from the Select Random blocks' children. This wouldn't be impossible to handle, but I think it would add too much complexity. The system already required handling 3 different cases for binding, and another 3 cases for unbinding. I think adding additional logic to propogate child updates to parents would make the system basically incomprehensible.

Additionally I think that all of these updates would pretty much cancel out the benefits gained by caching bindings instead of doing type lookups (as discussed here).

Plan

So my plan is to try out the type lookup method (again discussed here). It may be less efficient (I'm not 100% sure) but it should be easier to maintain. This could cause there to be a delay in my PRs as I work through things though.

Conclusion

But yeah! As I said this doesn't require a response. I just wanted to give you peoples a heads up incase there is a gap in my PRs =)