Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

More flexible typedef editing #1142

Open
1 of 6 tasks
georgefst opened this issue Sep 12, 2023 · 0 comments
Open
1 of 6 tasks

More flexible typedef editing #1142

georgefst opened this issue Sep 12, 2023 · 0 comments
Labels
tracking This is a tracking issue

Comments

@georgefst
Copy link
Contributor

georgefst commented Sep 12, 2023

We can now construct any type definition through the actions API (sort of, see first bullet point). However, we still have several restrictions:

  • We cannot attach name hints to student-defined types. The backend outputs them but we just don't have actions for them. We may very well not want to expose this to students. But it is technically the one way in which we can have an ASTTypeDef value which cannot be constructed via the OpenAPI API. And we have discussed wanting to edit these in our frontend: Add tooltips to nodes in tree view primer-app#19.
  • We can only delete things from types if the type is not in use: Editable typedefs: deletion #401.
  • We can only modify the kinds of types if they are not in use: Editable typedefs: type parameters #402.
  • We cannot re-order constructors, fields or parameters.
  • We cannot add constructors and fields at positions other than the end of the list.
    • We could, for example, offer "insert a constructor to the left" and "insert a constructor to the right" actions on existing constructors. This doesn't seem like great UX to me.
    • This is in a sense an instance of a more general problem. It's similar to how, for example, we can't choose which child the selected node becomes when inserting an application above it, or how we'd like to choose which field to "eta-expand" over. We may want a new API (and ultimately UI) for these sorts of interactions, e.g. a new kind of input action which takes an index.
  • When we have named fields (Field names for value constructors #1108), we will want to be able to edit these.

I intend to open fresh issues for those points above which do not currently have one. There may in some cases still be relevant discussion in #267, e.g. on re-ordering.

@georgefst georgefst added the tracking This is a tracking issue label Sep 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
tracking This is a tracking issue
Projects
None yet
Development

No branches or pull requests

1 participant