User-definable operators are a questionable feature of Haskell; they get you >>= and <$>, of course, but the problem is that the entire sigil namespace is already filled, and these operators are often indecipherable.
In the most limited case, some people treat let-scoped operators as valid, for instance, when doing:
hs let (@) = (,) in [insert long list of tuples, perhaps for Data.Map inputs]...
But the problem still arises that since the single character operator namespace is almost fully occupied on Hoogle-Stackage, you’re almost always overriding an existing operator, with @ and ~ being the sole exceptions, and these are used in as-patterns and irrefutable patterns.
I’m still adhering to the “don’t define your own operators” part of the style guide, since custom operators are less readable, but if people ARE going to define their own operators as part of libraries, emojis solve the namespace problem, and well, are fun, and brighten up your day when you’re working on code that involves and it has a valid reason to do so.
Well, I’m taking from Kowainik’s, but yeah, I don’t like introducing new operators in global scope, but I do understand why people may wish to do so.
To some extent, this is an absurdist retort to people claiming that Haskell has too many unfamiliar operators: “Not anymore! We’re using emoji now. ”.
In all seriousness, I do think that Emojis should be taken seriously, even though there are serious compatibility issues with ghci at the very least.
Assume a particular use case, someone is teaching Haskell and is defining a datatype that represents a robot.
Would it be more memorable for students to see
data Robot = MkRobot {...}
or
data (🤖) = (:🤖) {...}
?
In the same way, assume that someone’s built a start-up, and the developers are working 72 hour weeks. Wouldn’t mild use of emoticons try to make the horrific grind a bit more fun, especially since start-up employees are often young?
A further reasonable usecase would be for libraries that rely on a single “run” function. Aliasing it to an emoticon, such as (), would help make the library memorable and distinctive, even if the emoticon is used only once. And yes, is part of miso’s branding, although miso is currently not using such an alias.
I support Unicode characters in source files where it helps understand what the code does. Unfortunately Unicode singles are a small fraction of the emoji in use across devices today, and most vendors have their own device-specific emoji sets that don’t work universally. Once your source files start moving across devices and off the desktop this becomes really difficult to deal with.
Even if we were able to solve the presentation problem, the meaning conveyed by emoji across cultures can vary wildly, and they’re rarely tools for precise communication, which is the end goal of source code in my opinion.
and it has a valid reason to do so.
”.
), would help make the library memorable and distinctive, even if the emoticon is used only once. And yes,