1. 31
  1.  

  2. [Comment removed by author]

    1. 4

      i like the >=, <= and != set too. most of the rest do look unnecessary.

    2. 5

      The ligation of == would completely throw me. I would end up making a doublet of ==.

      1. 1

        Agreed. I’d imagine Javascript programmers might have an issue with that, since the ligatured versions of == and === are more difficult to distinguish from each other.

      2. 5

        I like the idea of this, but it doesn’t work in any of the editors I use.

        1. 4

          I’m not so keen on some of these ligatures. The # ones in particular seem a bit poorly designed. But I hope more people try to make ligature fonts and more people try to get editor support working (emacs and vim being notable unsupported editors). I think this could be done really well eventually, so I applaud any effort in that direction.

          I’ve tried another ligature code font, Hasklig, and it’s great, though obviously Haskell-centric, and it’s not supported in my main editor right now.

          1. 3

            I’m glad people are experimenting here, since notation is so fundamental to thought.

            To your note about vim support: I am a bit concerned about two things:

            1) Rectangular selections 2) Character-oriented motions

            I’m concerned about what happens when your selection or cursor cuts a ligature; or when you want to move to the all or part of the ligature’s character sequence. As an example of the latter, consider the <= and >= operators. The ligatures give no hint that the equal sign is the second character, so how do I know what happens if i type f= or t> to move to a ligature? It may or may not be confusing, but I’m sure that there are many more subtle issues to consider, so, again, I’m glad people are experimenting here.

            1. 1

              Thanks for bringing up those points.

              I’m not sure what’s the best way to handle half-selected ligatures, but my first thought would be to temporary undo the ligature to show the raw characters (kind of like how vim’s conceal feature works). Or you could just leave the ligature as-is and make the programmer infer what’s actually going on. They should know what their ligatures actually stand for regardless.

              I never thought about the effect on commands like f= and t> before, but again I think it would be reasonable to assume the programmer should just know that ≥ means >=. You would lose on the quick eye scanning and spotting a = to jump to, though, so that’s something to consider.

              And +1 to experimenting with notation. I see ligatures as one of the easiest ways we can go beyond ASCII without really leaving ASCII. In comparison, adding unicode to programming languages usually gets shot down a lot faster, which is fair since it’s a lot more problematic.

          2. 4

            Some of these are great, but the creator obviously got carried away with the likes of #{. Not every two symbols which sit next to each other in code need to or should be a ligature. However, I really like >=, ->, !=, >>, &&, ||, <=>, etc. Particularly silly are the comment prefix ligatures. I think I’d be happy if all the ligatures which reduced the kerning were dropped and the ones which substituted in symbols of significance remained.

            1. 4

              Yes. I like the idea a lot more than I like the implementation. If a symbol isn’t legible, it shouldn’t be in the set until a better rendition is invented.

              I hope the ones that just tweak the kerning are done via the actual kerning table, and not the ligature tables. :) But I suppose that only matters to the font maintainer…

            2. 2

              I don’t know that I actually like this idea - I spent a bunch of time this winter annoyed at Hutton’s Haskell book because he used lovely typography in his code samples and I had a mental translation tax on top of the difficulty of learning Haskell.

              1. 4

                It’s certainly an improvement over working in a codebase where some contributors are fans of Unicode in Haskell, and others are not. :) Without changing my editor, the only way I was able to match the style for Unicode files was to copy and paste. The nice thing about doing this at the font level is that it makes the typography something each user can decide for themself.

                That said, no, I wouldn’t use this as it stands. I would use it for the comparators, but not for ==. That one actually gets culturally understood by non-programmers, at this point. :)

              2. 2

                Excited to give this a try.

                For those that use Vim, you can also use the conceal functionality to replace sequences with other symbols. Example: https://github.com/enomsg/vim-haskellConcealPlus

                The original characters are shown when the cursor is on the line.

                1. 2

                  For emacs, one can use the display text property to show the utf8 characters instead of the sequences that’d normally be displayed (eg replacing -> with )

                  I don’t know of any extensions off the top of my head that’d do all of the haskell ones in one shot, though I’m sure the community would appreciate it if there were one.

                2. 2

                  Not exactly on topic but am I the only one finding the screenshot blurry? I’d be guaranteed a migraine working with display like this for more than a few minutes.

                  1. 1

                    It’s being scaled down by your browser. Try the full size image.

                  2. 1

                    The ligatures were a bit too buggy in my editor, but I did like the font itself so I was happy to find that it’s based on Fira Mono, so I can get a similar-looking font.