Skip to content

Add bowties and deprecate join #93

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.

Sign up for GitHub

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

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open

Add bowties and deprecate join #93

Changes from 2 commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
50ba089
Add bowties and deprecate `join`
T0mstone Jun 30, 2025
2b76536
"It's bigger than that, Chris, it's large"
T0mstone Jun 30, 2025
847cdcd
Add stroked to big and change order
T0mstone Jul 3, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 10 additions & 0 deletions src/modules/sym.txt
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -584,10 +584,20 @@ diameter ⌀
interleave ⫴
.big ⫼
.struck ⫵
@deprecated: `join` is deprecated, use `bowtie.big` instead
join ⨝
.r ⟖
.l ⟕
.l.r ⟗
bowtie
.stroked ⋈
Copy link
Collaborator

Choose a reason for hiding this comment

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

I think it makes more sense to just put this at the top level (without stroked), unless there are additional variants not included here.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

That's what I had originally, but my thinking was that it makes more sense to keep .stroked when there's also .filled. That's also how it is for e.g. hourglass.

Copy link
Collaborator

@Enivex Enivex Jul 1, 2025 •
edited
Loading

Choose a reason for hiding this comment

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

Currently we aren't entirely consistent (which we ideally should improve upon), but in my mind it makes more sense when there is no canonical variant. In this case the stroked one is the canonical variant, and stroked just serves as extra noise.

Not to mention the big variants are variants of the stroked ones.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Remember that it's not required. Since stroked is the first variant, bowtie is automatically a shorthand for bowtie.stroked. A part of me thinks that users could be confused when some symbols only have stroked available as a modifier and some only have filled.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Remember that it's not required. Since stroked is the first variant, bowtie is automatically a shorthand for bowtie.stroked. A part of me thinks that users could be confused when some symbols only have stroked available as a modifier and some only have filled.

I know that it's not required, but I don't think that's a good reason to add unnecessary modifiers.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Notice how the unicode names mention "black" specifically, but not "white" for the regular ones.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I really don't want the added complexity of enshrining a "canonical version" for some symbols by means of omitting certain modifiers for them. That's another data point users will have to remember and seems like a totally unnecessary restriction. It's conceptually so much simpler to just have both modifiers for everything with those two styles, whether one of them is canonical or not.

Copy link
Collaborator

Choose a reason for hiding this comment

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

I would say that having .stroked is more complexity, not less. Why should I have to arbitrarily have to remember which operators get the stroked, only because they have a filled variant? I do not like relying on fallback, because it's unpredictable and brittle to codex changes. Almost everyone who want these symbols will want the .stroked variants.

Copy link
Collaborator

Choose a reason for hiding this comment

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

I do not like relying on fallback

But fallback is a feature. If you choose not to use it, then of course you may have to specify annoying modifiers.

My view is that most changes do not affect fallbacks. When they do, we should be careful about it. And we should have a way to specify which fallbacks can be relied on, and which cannot (e.g., with the minimal modifier set proposal I link everywhere).

Copy link
Collaborator

Choose a reason for hiding this comment

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

I agree having some symbols with "canonical version" and some without is annoying.

Why should I have to arbitrarily have to remember which operators get the stroked, only because they have a filled variant?

Beyond the fact that you don't have to know that (thanks fallbacks), I like that I can know there's a 'stroked' if there's a 'filled' and vice versa. So I think having stroked/filled consistently is a net win if we can sort out the documentation/symbol page to be clear that stroked is optional, and have it clear for us also in the sym.txt format (e.g. as implemented in #105).

.filled ⧓
.filled.l ⧑
.filled.r ⧒
.big ⨝
.big.r ⟖
.big.l ⟕
.big.l.r ⟗
hourglass
.stroked ⧖
.filled ⧗
Expand Down