Skip to content

Node styling improvements#997

Merged
georgefst merged 4 commits into
mainfrom
georgefst/zurihac-nodes
Jun 29, 2023
Merged

Node styling improvements#997
georgefst merged 4 commits into
mainfrom
georgefst/zurihac-nodes

Conversation

@georgefst
Copy link
Copy Markdown
Contributor

@georgefst georgefst commented Jun 29, 2023

This is a cleaned-up version of the bulk of #980/#987.

I've fixed up comments and commit messages, and rebased to fold last commit in earlier. I also fixed a bug where edges out of THole were invisible - this turned out to be due to a typo (stroke-red-tertiaryy).

* Note that the backend could in principal tell us this independently of flavors,
* since it comes down to whether the node ultimately comes from an `Expr`, `Type` or `Kind`.
*/
export const isTypeLevel = (flavor: NodeFlavor): "term" | "type" | "kind" => {
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a good name for "type or term or kind"? The existing naming here was just about okay when we weren't considering kinds, but now it's misleading.

Copy link
Copy Markdown
Contributor Author

@georgefst georgefst Jun 29, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@brprice says "sort" - I'll change this (along with the "principle"/"principal" typo I just noticed here).

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would probably use "sort". It is used this way in Pure Type Systems.

@dhess
Copy link
Copy Markdown
Member

dhess commented Jun 29, 2023

My Internet is currently brutally bad, so I won't be able to meaningfully review this. So long as it's more or less in line with #987, I'll be OK with it.

@georgefst
Copy link
Copy Markdown
Contributor Author

My Internet is currently brutally bad, so I won't be able to meaningfully review this. So long as it's more or less in line with #987, I'll be OK with it.

There's no difference in functionality, just some minor code changes. I'd merge, but CI is blocked due to some Vault issue.

The choices of shape are somewhat arbitrary, but there is a little logic to it: types are rectangular because they're in a sense more "rigid", and kinds are drawn as diamonds since each node currently only has a single character.

We considered using `clip-path`, instead of rotation, to create the shape for kinds, but this makes drawing borders difficult as they don't follow the path. The usual trick would be to add a dummy background to create a manual border, but this quickly gets messy when we don't want it for the type or term case.

Signed-off-by: George Thomas <georgefsthomas@gmail.com>
Well, almost all. We still use black for type annotations due to running out of colours in our existing palette.

We try to colour type nodes analogously to corresponding term nodes. This makes more sense now that we use different shapes for terms and types, but it probably requires a little more thought. For example, it may seem odd that we style term `Lam` and type `LAM` differently, since we choose instead to highlight their analogies with `TFun` and `TForall` directly.

We should consider refactors to make this sort of change less laborious, though it's hard to say how to abstract colours properly when tailwind discourages concatenating class strings.

Signed-off-by: George Thomas <georgefsthomas@gmail.com>
Signed-off-by: Drew Hess <src@drewhess.com>
This covers _all_ sorts of application: term-to-term, term-to-type, and type-to-type. We were already using `@` for two different concepts, so we may as well unify all three. And `$` is a weird Haskell-ism that isn't really used elsewhere. We can now easily tell which sort of application is in use by the shape of children.

Signed-off-by: George Thomas <georgefsthomas@gmail.com>
These seem redundant, since patterns already look so different to everthing else. We may wish to re-introduce these in beginner mode.

Signed-off-by: George Thomas <georgefsthomas@gmail.com>
@georgefst georgefst force-pushed the georgefst/zurihac-nodes branch from f564ff1 to 01592cb Compare June 29, 2023 17:02
@georgefst georgefst enabled auto-merge June 29, 2023 17:02
@georgefst georgefst added this pull request to the merge queue Jun 29, 2023
Merged via the queue into main with commit 881b47f Jun 29, 2023
@georgefst georgefst deleted the georgefst/zurihac-nodes branch June 29, 2023 17:07
@georgefst georgefst mentioned this pull request Jul 3, 2023
github-merge-queue Bot pushed a commit that referenced this pull request Jul 3, 2023
@georgefst georgefst mentioned this pull request Nov 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants