Haskell In New Clothes (opens in new tab)

Mathematics is usually written in something like Haskell syntax (or typically more extreme on the C-Haskell axis). It would not be surprising to use some random symbol to represent a binary operation the author thinks is important. In Haskell, juxtaposition of non-keywords always means application (function application, or type constructor application) or alludes to it in a pattern match. In mathematics the following: f g h x might correspond to any of the following Haskell depending on context:

  f (g (h x))
  f . g . h . x
  x . h . g . f
  x . h . g $ f
  (f <> g <> h <> x) -- potentially more a type-dependant operation than <>
  (f <> g <> h) <%> x -- For some operation <%>

Furthermore Haskell is only indentation sensitive whereas mathematics notation depends on alignment and structure in two dimensions more generally.

Therefore I claim it is silly to talk about mathematics notation as if it were a single standard thing because the reality is that mathematics notation depends on context a lot and varies a huge amount by situation. It is not obvious that the kind of elementary algebraic notation one might encounter in high school is the best fit for programming which tends to deal with totally different things.

I actually think Haskell makes a pretty good language for a small group as it may be better moulded to the problem domain. I recall an example from a mailing list where someone defined:

  (.) x f = f x -- for my poor OO brain
  infixl 9 (.)

So they could write code like:

  prodSize xs ys = xs.length * ys.length

Which seems silly except that the user has adapted the language to fit themselves. Some mathematicians also prefer function application/composition on the right. It makes values pass through functions from left to right the same way that their types are written.

Given the response a lot of people have to Erlang's syntax (borrowed from Prolog), that has commas, periods, and yes, meaningful casing distinctions (atom vs variable), I'm going to go out on a limb that any benefit from scansion is offset by effort in writing.

Further, I'll go out on a limb and say that the benefit of reading has NOTHING to do with audience reception of the syntax (whether that audience is new to the language, or extremely experienced with it), and instead has everything to do with what seems familiar. (I.e., I think I'm in agreement with you in that it's what people's habits are as to whether it's appreciated or not; I'm just disagreeing that improved readability is a factor in whether people appreciate the extra boilerplate, or the possible implication that it's a net gain)

What math notation uses curly braces and angle brackets? All math notation is terse and focused on efficient expressions of ideas. Haskell syntax is much closer to all of math than C-families.

> What is this ungodly mess?

    type API = "polls"                                           :> Get  '[JSON] [Poll]
          :<|> "polls" :> Capture "question_id" Int              :> Get  '[JSON]  Poll
          :<|> "polls" :> Capture "question_id" Int :> "results" :> Get  '[JSON]  PollResults

Delightful :D

  The API is the route "/polls" accessed via GET, returning a list of Polls in JSON format
          or the route "/polls/question_id" where question_id is an Int, accessed via GET, returning a Poll in JSON format
          or the route "/polls/question_id/results" where question_id is an Int, accessed via GET, returning PollResults in JSON format

> And coming up against arbitrary three-four-character combinations people come up with for their operators.

Nothing requires that though, it's more of a debatable community habit, similar to the overly abstract or cutesy names.

> At least mainstream languages are usually consistent. A method call is a method call. A structure is a structure. What is this ungodly mess?

Haskell is arguably way more consistent there: "mainstream languages" also have operators, often overloadable, you just can't declare your own operators in most of them.

Haskell simply allows sigils to be used as infix functions, aka binary operators, and furthermore allows those to be used as prefix functions, as well as prefix binary functions to be used infix.

> What is this ungodly mess?

An eDSL ? Much like every DSL, it requires to invest some time learning, and gives you something if you take that time. It's not really specific to Haskell.

Back when I was doing some Java, I had to learn the logic of maven xml files, and it was exactly the same kind of investment-for-future-reward.

it might look weird to the foreign eyes but essentially this is just a typed api with 3 routes.

/polls returns an array of Poll. /polls/:question_id returns a Poll. /polls/:question_id/results returns a PollResults.

the thing you call a mess is the combination of type level operators which helps you describe your API which is the essence of functional programming.

If you're doing combinator parsing, the offside combinator is a few lines. I have one in front of me as part of a demo Haskell-like syntax for Scheme as a command processor. You have to tag the lexemes with position information, but you presumably want that for error-reporting anyhow.

[As others have pointed out, you get the choice of layout in Haskell syntaxes and, as it happens, that Scheme syntax also allowed you to use sexp input.]

The indentation-sensitive part is probably not a big issue though, Python does well :-)

This is not an accurate description of notation as it is used in mathematics. All types of brackets (round, curly, square, angled, ...) are used in mathematics for grouping things. Typically parens for innermost small groups and other brackets for larger “outer” groups.

Curly brackets may be used for sets but they are also used for different cases of functions, or as a more succinct and precise way of expressing sentences about multiple things than writing “foo, respectively bar” all over the place, or for Stirling numbers of the second kind, or for whatever other things an author might want.

Other “structure making” notations like group presentations use angle brackets. Ideals are sometimes written with their generators in angle brackets, sometimes with round brackets. Similarly tuples or sequences may be written with either.

Matrices are sometimes written with square brackets and sometimes round, and never with commas. Vectors typically are written with round brackets but may be square. Row vectors sometimes have commas.

Function application is sometimes written with round brackets. Arguments are sometimes separated by commas, sometimes by semicolons, sometimes with one argument as a subscript or implicit. Application often omits brackets altogether. Sometimes the function goes on the left, sometimes it goes on the right.

Now consider the few features which I find are relatively common to different mathematics notations are context, alignment and structure in 2 dimensions, juxtaposition, implicitness, and terseness. I think I see basically none of these in the common C/Rust style syntax you claim to be so rooted in mathematical notation, and indeed I would guess that you would oppose them.

I don’t buy your arguments at all.

Square brackets because they look like matrices perhaps?

> they've been better about removing the feature flag when the feature is stabilized.

The developers of rustc define the language, while the developers of GHC are trying to be first an implementation of a purportedly independent standard.

I don't raise this as defense or attack on either side, but I think it's an important bit of context in understanding the differences.

Hmm, those are language _features_ not language _extensions_, right?

And yes, I think the Rust comparison is a great one – I'm not the sort of person who would want to use nightly Rust and turn on feature flags; I'd want to use Stable rust with no extra features.

From what I dimly remember last time I looked, there were a bunch of ways to deal with strings and lists/arrays/etc.

Googling "most popular haskell language extensions", I see this article: https://lexi-lambda.github.io/blog/2018/02/10/an-opinionated... which lists 34 recommended extensions and admits "a few of them are likely to be more controversial than others". Half of them don't have names which make their purpose immediately obvious to me.

A more data-driven approach is turned up here: https://gist.github.com/atondwal/ee869b951b5cf9b6653f7deda0b... which concludes "only 10 extensions show up in more than 10% of the Haskell files on GitHub, and 20 show up in more than 5%!"

Its discussion on reddit (https://www.reddit.com/r/haskell/comments/916jj0/popularity_...) highlights some gaps in the analysis, but also the general notion that "everybody uses language extensions, but not everybody uses the same ones".

Of course, each language extension changes the syntax and/or semantics of the language, so in order to "learn Haskell" I'd have to learn one or more flavors/styles of it – and there doesn't seem to be one standard set of language extensions that are commonly used.

I would have used the word "features" or "extensions" instead of "styles" but I agree with rattray's point, if I understand it correctly. It seems like every Haskell project makes use of a different subset of 10 to 20 language extensions, each of which requires some deep knowledge of type theory to understand how it affects the language.

This makes me feel that, totally apart from the syntax, Haskell/GHC is still more of a laboratory for doing programming language research. Which is great for what it is; I would say Haskell's original motto "avoid popularity at all costs" still holds. I also had hope for languages like PureScript that make an opinionated choice about a subset of those features for the sake of a consistent development framework.

To reply to both of your respondents at once,

> Of course, each language extension changes the syntax and/or semantics of the language, so in order to "learn Haskell" I'd have to learn one or more flavors/styles of it – and there doesn't seem to be one standard set of language extensions that are commonly used

> It seems like every Haskell project makes use of a different subset of 10 to 20 language extensions, each of which requires some deep knowledge of type theory to understand how it affects the language.

These comments are both pretty off the mark. It's unhelpful to think of language extensions (the most commonly-used ones at least) as extending the language. It's more that there is one overall Haskell language and the absence of a particular language extension disables a particular feature. The language is, by and large, more coherent with language extensions turned on, not less coherent.

> What are the advantages of white-space insensitive code for refactoring and formatting?

For refactoring, it's less error prone when you're using an editor without refactoring support for it, would be my guess.

For indent/format, your guess is as good as mine, AFAIK programs don't care whether block separators are called INDENT or {. Though the parsing of the latter would be somewhat trivially simpler as you don't need to store a stack of indent levels.

With white-space insensitive code I can easily cut/paste code from one function to another, without having to potentially manually re-indent it afterwards. This makes refactoring easier.

For formatting, it means I never need to manually add any spaces or tabs: the formatter always knows exactly how to indent it. With whitespace-sensitive code, I have to manually pick the indentation, as different indentations could have different semantics. That's why if I hit tab in Emacs when editing a Haskell file, it will cycle through multiple possible indentions. If I hit it in a whitespace-insensitive language, it will just move it to the "correct" indentation straight away and I don't need to worry about it.

Using {} braces in Haskell seems less intuitive, at least to me. E.g. how would I use braces to avoid the need to manually indent a nested where statement?

The fairly popular `LambdaCase` extension gives

  fib = \case
    0 -> 0
    [...]

&& is always strict in its first argument. Pattern matching is strict. It's hard to predict when some random function you call with force a thunk you've passed it. My position is still that lazy-by-default is a really bad evaluation policy and that consequently, Haskell is a dead end in language evolution.

Standard, base Haskell admits the following definition:

  let f lst = lst 
              & map normalize
              & filter (\x -> x > 0)
              & average

Which is barely different from your second presentation. (EDIT: just in case you think I'm ass-pulling here, this is fairly idiomatic code that I'd certainly write in prod! See another comment I posted earlier this week...)

> Most popular languages created sort of universal visual language of what things mean when they look certain way

python kind of ignored this "universal visual language", and the language seems pretty popular with newcomers.