2 ms·

> If your arguments aren't exclusive, you can pass a list of algebraic data. Which you need to prefix to avoid clashes. > If they are exclusive, you can const

> If your arguments aren't exclusive, you can pass a list of algebraic data. Which you need to prefix to avoid clashes. > If they are exclusive, you can construct a type for them. Which is going to end up being a record, which: - is awkward to build (compared to just giving options to a command or arguments to a function) - will most likely need to be an instance of Default - which needs to have its fields prefixed to avoid clashes Starts to sound like an awful amount of boilerplate.

vlastachu 12y ago
> prefixes, default instances Also bad setters ("record {field = val}" looks nice but useless, as not a function). I hope the developers of GHC also clearly see the problem and someday will be engaged in it. Then the language becomes much more expressive. Is that task exists somewhere in roadmap?
- joelwilliamson 12y ago
  There has been quite a bit of discussion on ghc-devs about fixing records. The most promising approach seems to here: http://nikita-volkov.github.io/record/ http://nikita-volkov.github.io/record/
- tel 12y ago
  There have been probably 15 different proposals for this throughout the years. They never make enough momentum to go through. While record pain points seem like a huge deal, in practice they're not sufficiently bad to motivate changes in the language in the face of the various tradeoffs that would have to be made. Today, typeclasses and lenses cover 99% of "the record problem" as far as I've experienced.
marcosdumay 12y ago
Prefixes are a problem, no arguing about that. But... > is awkward to build (compared to just giving options to a command or arguments to a function) Idiomatic bash: apt-get install package_name Idiomátic haskell: apt_get $ AptInstall package_name What is so awkward about that?
- mercurial 12y ago
  First, it doesn't let you install multiple packages in one go (or let you install a specific package version). Secondly, it doesn't support apt-get options like -m, -d -n... You could extend your argument structure for this, but then you need to specify every argument all the time, or have the user modify a default value. This is definitely awkward compared to straight shell.

vlastachu 12y ago

> prefixes, default instances Also bad setters ("record {field = val}" looks nice but useless, as not a function). I hope the developers of GHC also clearly see the problem and someday will be engaged in it. Then the language becomes much more expressive. Is that task exists somewhere in roadmap?

joelwilliamson 12y ago
There has been quite a bit of discussion on ghc-devs about fixing records. The most promising approach seems to here: http://nikita-volkov.github.io/record/ http://nikita-volkov.github.io/record/
tel 12y ago
There have been probably 15 different proposals for this throughout the years. They never make enough momentum to go through. While record pain points seem like a huge deal, in practice they're not sufficiently bad to motivate changes in the language in the face of the various tradeoffs that would have to be made. Today, typeclasses and lenses cover 99% of "the record problem" as far as I've experienced.

marcosdumay 12y ago

Prefixes are a problem, no arguing about that. But... > is awkward to build (compared to just giving options to a command or arguments to a function) Idiomatic bash: apt-get install package_name Idiomátic haskell: apt_get $ AptInstall package_name What is so awkward about that?

mercurial 12y ago
First, it doesn't let you install multiple packages in one go (or let you install a specific package version). Secondly, it doesn't support apt-get options like -m, -d -n... You could extend your argument structure for this, but then you need to specify every argument all the time, or have the user modify a default value. This is definitely awkward compared to straight shell.