Timeline for Why are "if elif else" statements virtually never in table format?
Current License: CC BY-SA 3.0
12 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
Aug 1, 2016 at 13:56 | comment | added | LarsH | You're right. I had missed that. Although it seems that the OP only uses "this simple kind of case/switch situation" to refer to the original if/elif/else example. So I wonder to what degree he really meant it. | |
Aug 1, 2016 at 7:23 | comment | added | viraptor | @LarsH The question text mentions switch/case as well, claiming they're just as uncommon - that's why I included them. | |
Aug 1, 2016 at 6:27 | comment | added | LarsH | Even in non-functional languages (C, Java), it's not uncommon to format simple case statements in a tabular way, one per line, like your elisp example. But switch/case is not quite the same as if / elif / else. | |
Jul 31, 2016 at 1:07 | vote | accept | horta | ||
Jul 30, 2016 at 18:02 | comment | added | Pharap | @viraptor Technically the other 50%- of haskell code is "non-trivial returns" because all haskell functions are functionally pure and can't have side effects. Even functions that read from and print to the command line are just lengthy return statements. | |
Jul 30, 2016 at 0:28 | comment | added | Claudia |
I think it's the pattern case syntax that promotes that. Because it's more concise and usually closer to a short switch-case, it's easier to express as one-liners. I frequently do this with short switch-case statements as well for similar reasons. Literal if-else statements are still usually spread across multiple lines when not effectively a simple ternary, though.
|
|
Jul 27, 2016 at 23:34 | comment | added | Jared Smith | Yes. I'm not a Haskeller but do some ocaml and find that pattern matching tends to be a lot more concise than logically equivalent switches, and polymorphic functions cover a lot of that ground anyways. I imagine Haskell's type classes would expand that coverage even further. | |
Jul 27, 2016 at 22:40 | comment | added | viraptor | @JaredSmith Thanks for the expression/statement based split - I think it may be even more fitting than functional/imperative. Than again ruby is almost expression based and doesn't use that convention often. (exceptions to everything) Regarding points 1 and 2, I find 50%+ of real Haskell code to be "trivial returns" that are just parts of something bigger - it's just how that code is written - not only in examples here. For example close to half of the functions here are one just one/two liners. (some lines use table layout) | |
Jul 27, 2016 at 22:30 | history | edited | viraptor | CC BY-SA 3.0 |
added 64 characters in body
|
Jul 27, 2016 at 18:03 | comment | added | Jared Smith | I upvoted this and generally agree, but feel obligated to point out that 1. All of these are trivial returns 2. Haskellers are fond of comically short identifiers in addition to the terseness of the language itself and 3. Functional languages tend to be expression based, and even imperative languages have different standards for expressions than statements. If the OP rewrote the original example as function applications he might get different advice... | |
Jul 26, 2016 at 23:49 | review | First posts | |||
Aug 10, 2016 at 19:06 | |||||
Jul 26, 2016 at 23:47 | history | answered | viraptor | CC BY-SA 3.0 |