Export atom constructors for parent types

[wdanilo]

This task is automatically imported from the old Task Issue Board and it was originally created by Edward Kmett.
Original issue is here.

---

Given a module with

type List a
   type Cons head tail
   type Nil

the List atom constructor does not get built today. #181908139 makes it so there is an actual constructor but doesn't add it to the export lists of the modules or give the user any way to actually reference it.

We need to export these from modules, use the actual names in scope rather than the hacked lookup provided by #181908139 in type signatures so that the type names are resolved to actual types rather than just arbitrary strings or local-only types, and restructure the maps from atoms and atom constructors to values.

In the new world there are 3 different types of methods that dispatch off of an atom or an atom constructor

List.foo

is a static method on List. It dispatches off of the atom constructor not the full atom.

List Int.foo

is an 'explicit static method' on List (which we don't support yet) or equivalently a member method on the atom List Int if we don't have a supertype.

Cons 1 2.foo
Nil.foo

are methods dispatched to the parent type. so using the vocabulary of #181908139, we'd dispatch them by following getParent() and then looking them up in a children member function list.

These wind up needing to be stored in 3 separate maps in the atom constructor due to the desire for parent type punning.

There's some expected impact to the standard library:

Vector will break, as will the current Json library and possibly Meta. Other breakage is possible.

My intent is to base on top of PR-3422 (#3422) while it is still unmerged, and rebase as needed after that gets squashed, most likely upon Dmitry's return on Tuesday, March 10th.

This then sets us up to be able to do the work for #181908162 as there will be a place for the statics to live and terms that can represent the atom constructors those hang off of in the system.

My current target to get this implemented is March 11th. Whether this branch will be mergeable before the statics work in #181908162 is complete will become clearer as we get closer to that date.

Blockers:

181908139 resolved

Comments:

Marcin Kostrzewa reports a new STANDUP for yesterday (2022-06-15):

Progress: started looking at Edward's code, then improved the test suite to be able to get to something testable. That's on main now, gonna move on to implementing statics to help with the naming conflicts introduced. It should be finished by 2022-07-01.

Next Day: Next day I will be working on the #same task. move on to implementic statics on top of this (Enso Bot - Jun 16, 2022)

---

**Marcin Kostrzewa** reports a new **STANDUP** for yesterday (2022-06-16):

Progress: Landed the micro-stdlib PR, came up with an elegant idea for how to implement statics. It should be finished by 2022-07-01.

Next Day: Next day I will be working on the #same task. Try to implement said idea (Enso Bot - Jun 17, 2022)

---

**Marcin Kostrzewa** reports a new **STANDUP** for yesterday (2022-06-22):

Progress: (this is actually a standup for 06-17) spent most of the day fighting with the IDE – on that day, the first piece of code using java 18 syntax landed on main and I had to upgrade intellij, which did not go smoothly, as is usually the case when upgrading intellij. Made very little actual progress It should be finished by 2022-07-01.

Next Day: Next day I will be working on the #same task. Actually write code (Enso Bot - Jun 23, 2022)

---