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

How could we improve the syntax? #22

Open
paolobrasolin opened this issue Feb 12, 2020 · 3 comments
Open

How could we improve the syntax? #22

paolobrasolin opened this issue Feb 12, 2020 · 3 comments

Comments

@paolobrasolin
Copy link
Owner

@tetrapharmakon suggests that repetitions quickly make code less readable

\mor A ["h",below]:[bend right,->] B;
\mor * ["k", above]:[bend left,->] *;
\mor * ["\sigma\Uparrow",black,mid]:[->,white] *;

and suggests the haskellism

\mor A ["h",below]:[bend right,->] <>
       ["k", above]:[bend left,->] <>
       ["\sigma\Uparrow",black,mid]:[->,white] B;

I feel a better (=clearer, less rigid) working alternative would be

\mor A ["h",below]:[bend right,->] B;
\mor A ["k", above]:[bend left,->] B;
\mor A ["\sigma\Uparrow",black,mid]:[->,white] B;

and an hypothetical improvement (more TikZ-like than the haskellism) could be

\mor A ["h",below]:[bend right,->]
       ["k", above]:[bend left,->]
       ["\sigma\Uparrow",black,mid]:[->,white] B;

Thus some questions are raised:

  • how can the syntax be improved staying in line with the TikZ way?
  • how can the syntax be improved (redesigned?) to make compositionality apparent?
  • are these two directions in contrast?
@paolobrasolin paolobrasolin self-assigned this Feb 12, 2020
@tetrapharmakon
Copy link
Contributor

@tetrapharmakon suggests that repetitions quickly make code less readable

\mor A ["h",below]:[bend right,->] B;
\mor * ["k", above]:[bend left,->] *;
\mor * ["\sigma\Uparrow",black,mid]:[->,white] *;

The white arrow is just a hack to draw a 2-cell.

The problem here is just that at the moment there is no way to draw parallel arrows avoiding repetition. Consider the diagram

\obj{A & B};
\mor A -> B;
\mor A [shove=.5em,->] B;
\mor A [shove=-.5em,->] B;

it would be way better (=more readable) to write

\obj{A & B};
\mor A              ->  <>
       [shove=.5em, ->] <>
       [shove=-.5em,->]    B;
  1. The code is more rigid, but more readable
  2. The whole point of koDi (if I remember) was to have easy to fix/visualize code for diagrams. This style of typesetting is very near to the actual diagram,
A -->
  -->
  --> B

is very similar to

  -->
A --> B
  -->

@paolobrasolin
Copy link
Owner Author

@tetrapharmakon suggests that repetitions quickly make code less readable

\mor A ["h",below]:[bend right,->] B;
\mor * ["k", above]:[bend left,->] *;
\mor * ["\sigma\Uparrow",black,mid]:[->,white] *;

The white arrow is just a hack to draw a 2-cell.

This is a less hackish 2-cell, perhaps:

\tikzset{2>/.style={-Implies, shorten >=2pt, shorten <=3pt, double equal sign distance}}

\begin{kodi}
  \obj { A & B \\ };
  \mor[below]:[bend right] A h:-> B;
  \mor[above]:[bend left]  A k:-> B;
  \mor h \sigma:2> k;
\end{kodi}

Screen Shot 2020-02-13 at 23 50 18


  1. The whole point of koDi (if I remember) was to have easy to fix/visualize code for diagrams. This style of typesetting is very near to the actual diagram,

Yup. I'm not sure about the <>, though. Do you have any specific reason for desiring it?

Currently,

  • whitespace in an arrow label requires wrapping it in ""
  • whitespace in an option (for both arrows and labels) requires wrapping it in []
  • whitespace in an object reference requires wrapping it in ()

In fact, whitespace is relegated to the role of separator between an object reference (e.g. (A)) and a labels:arrow block (e.g. ["f"]["g",below]:[->,red]). The latter admits many (or zero) option lists for labels on the left and a single (mandatory) option list on the right for the arrow.

This means that there would be no ambiguity in expressions like

\mor A -> -> -> B;
\mor A -> ->,red [->,light blue] B;
\mor A ["f"]["g", below]:[bend right, ->] ["h"]["i", above]:[bend left, ->] B;
\mor A ["h", below]:[bend right, ->]
       ["k", above]:[bend left, ->] B;

Ignoring the fact that parsing is harder without it, does the <> add something I'm missing?

@paolobrasolin
Copy link
Owner Author

Nevermind. Not using any kind of separator is ambiguous:

\mor S [...][...]:[->] T;
% The first block could be both a label and an arrow:
\mor S ["f"]["g"]:[->] T;
\mor S [->] ["g"]:[->] T;

I wouldn't mind a simple comma to concatenate arrows:

\mor S f:-> T g:->, h:-> U i:->, j:->, k:-> V;

That would entail losing the chance to use non delimited arrow option lists:

\mor S f:->,red T;
would be interpreted as
\mor S ["f"]:[->] []:[red] T;
instead of
\mor S ["f"]:[->,red] T;

That might be for the best, though: I think it

  • is not a great ergonomics loss
  • helps a lot with parsing parallel arrows
  • forces to use delimiters for arrow option lists with more than an item -- or a single user defined key (both feel like better code to me)

The initial use case would look like

\mor A ["h",below]:[bend right,->],
       ["k", above]:[bend left,->],
       ["\sigma\Uparrow",black,mid]:[->,white] B;

What do you think, user zero? @tetrapharmakon

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants