Signed-off-by: George Thomas <[email protected]>

This will be necessary in order to make use of them in actions-related modules.

Signed-off-by: George Thomas <[email protected]>

We parameterise this way, rather than parameterising `ExprMeta` and `TypeMeta` separately, since we otherwise wouldn't be able to reconstruct even a basic `Selection' ID` from the OpenAPI API, without clients knowing whether a particular ID corresponds to a type or term. We want clients to be able to be dumber than that.

Note that, for `Selection`, we use a synonym for the non-parameterised version, but not for `NodeSelection`, and we will not in future for `DefSelection` and `TypeDefSelection`. That's because this synonym is actually widely useful, and we use it in several modules to make things more readable. With `NodeSelection` etc. we never really require such a synonym, and we avoid it because of all the ceremony it would add, particularly around imports.

Signed-off-by: George Thomas <[email protected]>

This will significantly decrease the amount of breakage when we unify our selection types.

Signed-off-by: George Thomas <[email protected]>

This removes some boilerplate where we converted between types which are essentially the same. That boilerplate would have become much bigger once we extend selections to cover type definitions.

Despite the previous commit, there is one small breaking change, seen in `openapi.json` (`meta` instead of `id`).

Signed-off-by: George Thomas <[email protected]>

Signed-off-by: George Thomas <[email protected]>

Signed-off-by: George Thomas <[email protected]>

This will make it easier to output typedefs in the API, due to increased uniformity with AST typedefs.

Note that these names aren't even currently used anywhere since we don't actually have any higher-kinded primitives, only ints and chars. These would be used if we added, for example, `IO` or `Array` primitives, in which case the names would be likely useful at least for _displaying_ primitive typedefs, even though they don't actually scope over anything like they do for ASTs.

Signed-off-by: George Thomas <[email protected]>

Signed-off-by: George Thomas <[email protected]>

Note that no new unit tests are added. This is because the underlying `ProgAction`s are already well-tested, e.g. in `unit_RenameType`. In due course, the property test `tasty_available_actions_accepted` will be generalised to cover typedef actions, which will therefore check that all of these new actions can be applied without error whenever they are available.

We don't yet expose actions for constructor fields (i.e. `Available.forTypeDefConsFieldNode` always returns `[]`), since making this work will, unlike the other positions, require changes to the core of the library.

We _could_ actually make all the `for*`s part of one definition, now that `Selection` is in `App.Base`. But we do actually use the individual functions in some tests, and with them separate, we have slightly more control, in that we don't need to provide as much context.

Note that most of the changes in this commit are actually knock-on effects of generalising `Selection` to cover type defs.

Signed-off-by: George Thomas <[email protected]>

This was motivated by a surprising deep equality failure on selections in a TypeScript frontend, due to a null field only present in one of the compared values.

Signed-off-by: George Thomas <[email protected]>

Signed-off-by: George Thomas <[email protected]>

Signed-off-by: George Thomas <[email protected]>

It is of little use now that we have the more general `ConFieldAction`.

Signed-off-by: George Thomas <[email protected]>

We can define these in terms of their un-primed equivalents, by choosing the correct applicative, so we effectively do so and then inline.

Signed-off-by: George Thomas <[email protected]>

Signed-off-by: George Thomas <[email protected]>