Node styling improvements#997
Conversation
| * 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" => { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
@brprice says "sort" - I'll change this (along with the "principle"/"principal" typo I just noticed here).
There was a problem hiding this comment.
I would probably use "sort". It is used this way in Pure Type Systems.
|
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>
f564ff1 to
01592cb
Compare
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
THolewere invisible - this turned out to be due to a typo (stroke-red-tertiaryy).