5 ms·

The thing is, basic algebra notation has two major advantages over ad-hoc operators in some Haskell library: (1) it is widely taught and understood and extremel

The thing is, basic algebra notation has two major advantages over ad-hoc operators in some Haskell library: (1) it is widely taught and understood and extremely widely applicable, and (2) each operator has a standard name that is widely explained. In contrast, most Haskell notation I've seen is either an ad-hoc invention for some library, or it is an ASCII version of notation in a niche domain like category theory. Even Haskell's >>= operator for flatMap/bind seems to be an invention, as far as I can tell the equivalent concept in CT is Kleisli composition, denoted by a sharp sign and the regular composition operator (as far as Wikipedia shows - I'm not formally trained in CT). Additionally, people rarely if ever give a proper name to this notation in Haskell, making it completely impenetrable to even represent the formulas in your mind. How am I supposed to read `user1 ^. name` ? When I see `∇⨯f` I know how to read it (del cross f, or nabla cross f, or curl f) because that was an explicit part of how I was taught the operation (and note that it is not an arbitrary digraph, it can really be computed as the cross product of the pseudo-vector nabla and f), but Haskell tutorials and documentation completely skip this step, in my experience.

rssoconnor 4y ago
Not that you would necessarily use the same words in Haskell, but I'm curious how you would read `user1^.name` in Pascal, or `user1->name` in C or `(*user1).name` in C? (Edit: I'd also be curious about `x += y` and `x << y` in C.)
- AnimalMuppet 4y ago
  user1^ is what the user1 pointer points to, if I remember my Pascal correctly. It's a structure and the .name says to take the name field of that structure. So ^. isn't a digraph, it's two separate operators. Same with your C example. It's doing the exact same thing in C, except the operators (* and .) are separated from each other. -> is a digraph. It means the same as `*.` I don't usually pronounce it, I just think of it as itself. If I have to say it to myself mentally, I say "sub". I'm not sure I've ever tried to say it aloud to a coworker; if I did, I might have said "arrow" or something. You do have to learn these things, just like you have to learn all the other operators. But simiones still has a point - at least the math-based operators are much more widely known and understood than the category-based ones.
  - anon291 4y ago
    But what are their names? That was the standard applied to Haskell.. that the operators needed well understood names. C++ does not have that. Worse still, C++ operators are completely unintellible without context. For example, '>>=' (commonly called bind in haskell) is well-specified. Anything I see it used with is going to be a Monad, and thus follow certain laws. Examining the imports, I can immediately tell what any operator is. In C++? Forget about it. The 'left-shift' operator which is supposed to shift bits to the left, can somehow also print things to standard output. In what world can the terminal be bit-shifted left? In fact, we understand this because no one reads 'std::cout << "Hello world"' as 'shift std::cout left by "Hello world", because such a thing is non-sense, whereas '1 << 2' is '1 shifted two bits to the left'. EDIT: And then, when you add in external libraries, it gets worse. `<<` can be used for creating lexers and parsers in boost if I recall correctly. Completely lawless, and, when you survey the ecosystem, also dangerous. So many bugs in C++ and such due to this.
    - rssoconnor 4y ago
      I agree. I do feel there is a double standard here. C gets away with using `->` and `^=` and `*foo.bar` mixes prefix and infix and postfix with hard to remember precedence rules; C uses `{` and `}` instead of `BEGIN` and `END` and no one bats an eye. But when lens libraries use operators, suddenly some people lose their mind. I perfer `rec^.field` with operators in lens for the same reason I prefer `ptr^.field` in Pascal over hypothetically writing `ptr DEREFERENCE ACCESS field` or `ACCESS(DEREFERENCE(ptr),field). It lets me hide what is essentially just plumbing-like-grammer behind operators in order to let me focus of the parts of the program related to the business logic at hand, namely `rec`, `ptr` and `field`. Otherwise the plumbing tends to drown out the more important parts of what is going on.
      - tsimionescu 4y ago
        First of all, some people's eyes already glaze over when looking at C. It's only accepted because it has become near ubiquitous in computing, and notation is much more palatable when it is consistent for a whole domain. This is a very important point that many people miss: the reason why Java, C#, JS, even C++ to some extent get away with lots of non-maths operators is exactly because they have chosen to copy each other. That's a very powerful thing. Second of all, even within C, these operators are ubiquitous. You will use . and -> and * to deref and & to take the address, and = for assignment, and ++ or -- for increment/decrement, and ==, &&, ||, ! for logical operators, and the <operator>= notation for applying a change to a variable, and [] for subscripting, in almost every program you right in C. Shortening a very common operation to a symbol is much more easily acceptable than shortening a more rarely used operation, or one that's specific to a library. Basically, the status quo in programming as I see it is this: it's OK to use symbols instead of words for (a) syntax in your language (C curly braces, dots), or (b) ubiquitous constructs that are used virtually all over any program (+=, *), or (c) if they are already well-known symbols in other popular languages, or in non-programming fields (such as the near-universal regex syntax). Even (a) and (b) benefit a whole lot from familiarity with other languages, as should be expected. They also still require proper names - which the C standard for example gives for every operator, as do C tutorials.
- tsimionescu 4y ago
  I haven't used Pascal, so I can't comment on that. user1->name : "user1 arrow name" (*user1).name : "value of user1 dot name" x += y : "x plus equals y" or "x increases by y" x << y : "x left shifted by y"; the C++ overload for output streams is a terrible one that also doesn't have a name.
JadeNB 4y ago
> The thing is, basic algebra notation has two major advantages over ad-hoc operators in some Haskell library: (1) it is widely taught and understood and extremely widely applicable, and (2) each operator has a standard name that is widely explained. > In contrast, most Haskell notation I've seen is either an ad-hoc invention for some library, or it is an ASCII version of notation in a niche domain like category theory. But that's my point! When it was introduced, none of the symbology of school algebra satisfied condition (1) or (2); it was ad hoc (perhaps supported by some reasoning—as Reade's for the equal sign being two parallel lines, "than which no two things are more equal"—or perhaps not), and was found fully as abstruse and obfuscatory as you find symbolic operators in Haskell. Even Arabic numerals were thought a device for lies and deception, compared to good honest Roman numerals, when first introduced.) If we hadn't adopted those operators anyway, then we'd still be writing out all our equations in words as Tartaglia did, and our mathematics would be the poorer for it; had we stopped our notation earlier, we would still, as in pre-Arabic numeral times, send our children to special advanced schools to learn multiplication. New notation when first introduced is confusing and strange, but, once made commonplace, enables new thought, so that what was a niche domain becomes commonplace. (For that matter, I'd disagree about (2). For example, there is a symbol called the vinculum that is used for many purposes in mathematics (https://en.wikipedia.org/wiki/Vinculum_(symbol) https://en.wikipedia.org/wiki/Vinculum_(symbol)). Probably almost everyone has used that symbol for one of its meanings, but I'd argue that very likely almost no-one knows its name.)
- tsimionescu 4y ago
  I'm not claiming + and = have some underlying meaning, of course they were taught. My main point is that symbols are only truly useful when they are ubiquitous in their field. Before that, they are obscure and should be avoided. If the Haskell community or the Lenses community wants to do the hard work of teaching everyone their new symbols, go right ahead. Until that work is done though, I would advice everyone to avoid using these symbols. In regards to the vinculum, it's true that I've never heard that name, but I learned different names for the different uses - not in English though, as I took mathematics in Romanian, and some of the terminology and even notation is not the same (for example, repeated fractions are denoted using parentheses, not a vinculum - as in 1/30 = 0.0(3)).

rssoconnor 4y ago

Not that you would necessarily use the same words in Haskell, but I'm curious how you would read `user1^.name` in Pascal, or `user1->name` in C or `(*user1).name` in C? (Edit: I'd also be curious about `x += y` and `x << y` in C.)

AnimalMuppet 4y ago
user1^ is what the user1 pointer points to, if I remember my Pascal correctly. It's a structure and the .name says to take the name field of that structure. So ^. isn't a digraph, it's two separate operators. Same with your C example. It's doing the exact same thing in C, except the operators (* and .) are separated from each other. -> is a digraph. It means the same as `*.` I don't usually pronounce it, I just think of it as itself. If I have to say it to myself mentally, I say "sub". I'm not sure I've ever tried to say it aloud to a coworker; if I did, I might have said "arrow" or something. You do have to learn these things, just like you have to learn all the other operators. But simiones still has a point - at least the math-based operators are much more widely known and understood than the category-based ones.
- anon291 4y ago
  But what are their names? That was the standard applied to Haskell.. that the operators needed well understood names. C++ does not have that. Worse still, C++ operators are completely unintellible without context. For example, '>>=' (commonly called bind in haskell) is well-specified. Anything I see it used with is going to be a Monad, and thus follow certain laws. Examining the imports, I can immediately tell what any operator is. In C++? Forget about it. The 'left-shift' operator which is supposed to shift bits to the left, can somehow also print things to standard output. In what world can the terminal be bit-shifted left? In fact, we understand this because no one reads 'std::cout << "Hello world"' as 'shift std::cout left by "Hello world", because such a thing is non-sense, whereas '1 << 2' is '1 shifted two bits to the left'. EDIT: And then, when you add in external libraries, it gets worse. `<<` can be used for creating lexers and parsers in boost if I recall correctly. Completely lawless, and, when you survey the ecosystem, also dangerous. So many bugs in C++ and such due to this.
  - rssoconnor 4y ago
    I agree. I do feel there is a double standard here. C gets away with using `->` and `^=` and `*foo.bar` mixes prefix and infix and postfix with hard to remember precedence rules; C uses `{` and `}` instead of `BEGIN` and `END` and no one bats an eye. But when lens libraries use operators, suddenly some people lose their mind. I perfer `rec^.field` with operators in lens for the same reason I prefer `ptr^.field` in Pascal over hypothetically writing `ptr DEREFERENCE ACCESS field` or `ACCESS(DEREFERENCE(ptr),field). It lets me hide what is essentially just plumbing-like-grammer behind operators in order to let me focus of the parts of the program related to the business logic at hand, namely `rec`, `ptr` and `field`. Otherwise the plumbing tends to drown out the more important parts of what is going on.
    - tsimionescu 4y ago
      First of all, some people's eyes already glaze over when looking at C. It's only accepted because it has become near ubiquitous in computing, and notation is much more palatable when it is consistent for a whole domain. This is a very important point that many people miss: the reason why Java, C#, JS, even C++ to some extent get away with lots of non-maths operators is exactly because they have chosen to copy each other. That's a very powerful thing. Second of all, even within C, these operators are ubiquitous. You will use . and -> and * to deref and & to take the address, and = for assignment, and ++ or -- for increment/decrement, and ==, &&, ||, ! for logical operators, and the <operator>= notation for applying a change to a variable, and [] for subscripting, in almost every program you right in C. Shortening a very common operation to a symbol is much more easily acceptable than shortening a more rarely used operation, or one that's specific to a library. Basically, the status quo in programming as I see it is this: it's OK to use symbols instead of words for (a) syntax in your language (C curly braces, dots), or (b) ubiquitous constructs that are used virtually all over any program (+=, *), or (c) if they are already well-known symbols in other popular languages, or in non-programming fields (such as the near-universal regex syntax). Even (a) and (b) benefit a whole lot from familiarity with other languages, as should be expected. They also still require proper names - which the C standard for example gives for every operator, as do C tutorials.
tsimionescu 4y ago
I haven't used Pascal, so I can't comment on that. user1->name : "user1 arrow name" (*user1).name : "value of user1 dot name" x += y : "x plus equals y" or "x increases by y" x << y : "x left shifted by y"; the C++ overload for output streams is a terrible one that also doesn't have a name.

JadeNB 4y ago

> The thing is, basic algebra notation has two major advantages over ad-hoc operators in some Haskell library: (1) it is widely taught and understood and extremely widely applicable, and (2) each operator has a standard name that is widely explained. > In contrast, most Haskell notation I've seen is either an ad-hoc invention for some library, or it is an ASCII version of notation in a niche domain like category theory. But that's my point! When it was introduced, none of the symbology of school algebra satisfied condition (1) or (2); it was ad hoc (perhaps supported by some reasoning—as Reade's for the equal sign being two parallel lines, "than which no two things are more equal"—or perhaps not), and was found fully as abstruse and obfuscatory as you find symbolic operators in Haskell. Even Arabic numerals were thought a device for lies and deception, compared to good honest Roman numerals, when first introduced.) If we hadn't adopted those operators anyway, then we'd still be writing out all our equations in words as Tartaglia did, and our mathematics would be the poorer for it; had we stopped our notation earlier, we would still, as in pre-Arabic numeral times, send our children to special advanced schools to learn multiplication. New notation when first introduced is confusing and strange, but, once made commonplace, enables new thought, so that what was a niche domain becomes commonplace. (For that matter, I'd disagree about (2). For example, there is a symbol called the vinculum that is used for many purposes in mathematics (https://en.wikipedia.org/wiki/Vinculum_(symbol) https://en.wikipedia.org/wiki/Vinculum_(symbol)). Probably almost everyone has used that symbol for one of its meanings, but I'd argue that very likely almost no-one knows its name.)

tsimionescu 4y ago
I'm not claiming + and = have some underlying meaning, of course they were taught. My main point is that symbols are only truly useful when they are ubiquitous in their field. Before that, they are obscure and should be avoided. If the Haskell community or the Lenses community wants to do the hard work of teaching everyone their new symbols, go right ahead. Until that work is done though, I would advice everyone to avoid using these symbols. In regards to the vinculum, it's true that I've never heard that name, but I learned different names for the different uses - not in English though, as I took mathematics in Romanian, and some of the terminology and even notation is not the same (for example, repeated fractions are denoted using parentheses, not a vinculum - as in 1/30 = 0.0(3)).