8 ms·
I love seeing new Haskell projects, though I personally would rather just stick with Haskell's clean syntax: data Maybe a = Nothing | Just a ...over this:
by curryhoward 6y ago
I love seeing new Haskell projects, though I personally would rather just stick with Haskell's clean syntax:
data Maybe a = Nothing | Just a
...over this:
data Maybe<a> {
Nothing,
Just(value: a)
}
I understand that programmers coming from mainstream languages might feel uncomfortable without all those angle brackets, curly braces, and parentheses (why do C-like languages have so many ways to syntactically group things?), so if this project helps them ease their way into Haskell I totally support it. However, a small part of the joy of Haskell is freeing yourself from the arbitrary syntactic boilerplate that most languages have.
- ithkuil 6y ago> why do C-like languages have so many ways to syntactically group things?) TL;DR math notation Because they are different things. Brackets are for types, curly braces are for "bodies" (struct definitions, initializers, statements, function bodies, control flow construct bodies), parentheses are for overriding precedence. There are obviously exceptions that don't fit in this general scheme: e.g. function call syntax is based on parentheses, so it's not just about precedence. All this is just a post-fact rationalization; this all comes from standard math notation. Math uses parentheses for function application. Math uses commas for arguments of functions of multiple variables. Math uses curly braces to state of things are defined (sets, inductive rules) etc. Math uses parentheses to override precedence. All the rest is that historical accident. Angle brackets were unused so they choose them for types. Square brackets for array indexing? No idea why
- deleted 6y ago[deleted]
- dan-robertson 6y agoThis 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.
- ithkuil 6y agoThere is another ingredient I failed to make explicit: c syntax was a product of the 70s and it was a tradeoff between writing a parser easily and designing a syntax that would feel reasonably natural to people used to other notations. Surely implicitness and tersness were wisely used in math notations then and now, but devising a formal syntax that would work for C at the time was likely deemed too much work for little gain. there is a lot of random decisions that shaped the C syntax, as it's ultimately a random even that so many modern languages have chosen to continue that trend. My point was more about why it's not completely irrational to use "many different grouping symbols" since math notation also uses many different grouping symbols (rather than arguing the exact reasons this or that symbol is used instead of something else)
- dboreham 6y agoSquare brackets because they look like matrices perhaps?
- dmitriid 6y ago> freeing yourself from the arbitrary syntactic boilerplate that most languages have. And coming up against arbitrary three-four-character combinations people come up with for their operators. Terser does not automatically mean better (or J and K would've won that argument a long time ago). At least mainstream languages are usually consistent. A method call is a method call. A structure is a structure. 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
- masklinn 6y ago> 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.
- kazagistar 6y agoThat makes it more consistent to write, but less consistent when reading.
- jraph 6y agoApart from looking like the usual math notation, this "boilerplate" is like punctuation in natural languages: it helps recognize and scan things fast. In many languages, you both start sentences with capital letters and end them with a dot. A bit redundant, right? But probably much easier and faster to parse. Many people put non-necessary parentheses in their mathematical expressions to help readers (and themselves!) understand them more easily. Sure, they could be left out, but this is not an optimization for the reader. In your example, your version looks cleaner, but I find more complicated expressions far more readable with parentheses, brackets and all that stuff present in the second version. This is between angle brackets? This is a type! I don't have to parse the whole expression to infer this. Expressions written with this "redundant" syntax are seekable. You don't need to read the whole book to pick the one thing you need to know and get on with your life. Redundancy also helps remove doubts on whether something is an error or is intended in complicated cases (good things these languages are strongly typed though, it helps a lot). At the end of the day, it's all a matter of taste and habits. Would math be usually written in an Haskell-like syntax, probably almost everybody would find it easy to read and beautiful. It's not, and therefore this kind of syntax probably (almost) only pleases people who are into these languages (because they've got used to it) and represents yet another obstacle for outsiders. I'd actually bet that this plays a role in the fact these languages are not more widely adopted. They make them look unreadable at first impression and people move on. It probably even prevent people from contributing to projects written in these languages. This is bad. I've been able to fix things written in languages I didn't know, but Haskell would probably be hard just because of its syntax, which is unfortunate. On the other hand, it's good to see and develop new / alternative ideas, including on syntax matters.
- dan-robertson 6y agoMathematics 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.
- niho 6y agoParsing a language like Haskell that does not use any parentheses and curly braces is slightly harder than a typical C like language (or Lisp for that matter). Haskell syntax is indentation sensitive, which require the parser to keep track of the indentation when parsing.
- jraph 6y agoThe indentation-sensitive part is probably not a big issue though, Python does well :-)
- pmontra 6y agoIt does well but I'm not happy when I move code around and have to manually fix the indentation level at destination and check if I inadvertently broke an if or some loop. My editor does it for me with other languages and I have one less source of bugs.
- jraph 6y agoI've noticed editors auto fixing Python indentation while copy-pasting. I think VSCode does it, so it's definitively a solvable problem :-) (I've disabled this feature in my main editor for a long time though, so I'm used to hit Tab/Shift+Tab as many times as needed when pasting)
- pmontra 6y agoYep, but no editor can decide if the code must align with the last line of a loop or be indented out of the loop. I got at least one bug in production because of that, and a test that didn't catch the error.
- jakear 6y agoVS Code tries to do it, but it’s heuristic based and generally fallible. (Disclaimer, work on vscode, not on python extension) I much prefer working in languages wherein the series of tokens absolutely defines the semantics (as opposed to Python where the series of tokens + the context define the semantics)
- Akronymus 6y agoI program almost daily in c#. I still prefer the previous syntax, because it is terse and not harder to read either.
- sukilot 6y agoQuite the glass house of stone-throwing there. Haskell has braces, parens, and brackets for grouping, plus just about everything on the keyboard can be used to define an operator, with a 9-level hierarchy of operator associativity.