davidgregory084 / inc Goto Github PK

At the moment we have Scalacheck generators for arbitrary well-typed programs but they are very simple and do not exercise any polymorphic code.

It would be very useful to figure out a way to generate arbitrary polymorphic programs so that we can ensure that well-typed polymorphic programs can be compiled.

At the moment we have generators for arbitrary well-typed monomorphic programs. This enables us to test to a limited degree that well-typed programs can be compiled successfully, but it does not provide any reassurance that ill-typed programs will fail compilation.

The only way that I have seen others do this is to generate well-typed programs and then make some small change to the program which breaks one of the inference rules for the type system. This is likely to be very tricky!

This is the canonical way to implement type inference algorithms with decent performance.

There are several implementations of union find in the Scala ecosystem (e.g. DisjointSets in typelevel/cats-collections) but it may be better to use or implement a mutable one.

The test suite generated a random program like so:

module Test.Main.Ku2h6o { let xm = (); let ef = (xg, ufl, m) -> ''' }

I haven't added support for char escapes yet. I changed this to

module Test.Main.Ku2h6o { let xm = (); let ef = (xg, ufl, m) -> '' }

and the output was even more unhelpful than usual. Probably need a special case for chars and strings to avoid this.

At the moment there are two formats in which trees can be printed:

• As pretty-printed sources using functionality provided by typelevel/paiges
• As pretty-printed Scala data structures using lihaoyi/pprint

The difficulty with this is that the pretty-printed sources display nothing related to the metadata embedded in the trees, whereas the pretty printed Scala data structures are far too difficult to read and interpret.

It would be nice to have some functionality to pretty print the trees as inc source but with name and type annotations added inline.

This is because it is implementation-specific as to whether they will be visible to the VM due to case-insensitive file systems. Discovered by running the codegen tests on a Mac.