7 ms·

Could you expand on what's the scope of the 'record' intrinsic? Is it used for as many things as Python's `dict`? I sure hope not, otherwise I'm wondering how a

Could you expand on what's the scope of the 'record' intrinsic? Is it used for as many things as Python's `dict`? I sure hope not, otherwise I'm wondering how anyone could have gotten much done in this language before.

stingraycharles 12y ago
It's more like a struct from C.
ARussell 12y ago
It's essentially Haskell's version of a class, except Haskell isn't object-oriented. It holds data. So yes, you could view it as a dict, of sorts. Except each key in this dict/record generates a top-level function.
- m_mueller 12y ago
  How did having no namespaces in these things not become a massive headache for everyone? That would be the absolute killer argument for me to immediately switch to a different language if somehow possible.
  - bodhi 12y ago
    > you cannot have two records share a field name in a single module (emphasis added.) I'm still a Haskell beginner, so I'm not the best person to comment on how this works out in practice.
  - stingraycharles 12y ago
    So far it's more an inconvience -- in practice it doesn't surface that often, since modules represent the namespaces in Haskell. If you run into naming conflicts very often, chances are your modules are not isolated enough. You don't use records as often as you use classes in an OOP language, for example. Having said that, a lot of projects seem to have a general Types.hs where they declare all the types they share between modules. This is a great solution for that.
  - mijoharas 12y ago
    My thoughts are that it is something of a headache, but the benefits of the language outweigh the pain-points, like this one, in many cases. I'd guess it's seen as one of the trade-offs you need to make for using a pure functional language. (I've yet to see many other languages with a type system as expressive as haskell).
  - merijnv 12y ago
    The main reason it's not a massive headache is simple: Records aren't used THAT widely. Sure, in C++ or Java everything has named fields, because that's the only thing you have. Most Haskell datatypes use ADTs without record syntax, which means fields aren't named. Personally I only use records for large-ish "configuration" datatypes which and I just don't use that many of those for it to be a real problem.
  - dons 12y ago
    Functions and lenses and module namespaces tend to alleviate the problem, not that it isn't annoying now and again. It does make some people go crazy though.
  - dllthomas 12y ago
    It's not quite true that you have no namespaces. Rather, in most languages a class or struct creates a namespace. In Haskell, it does not. Record accessors are still constrained by module. There are also data types where the fields are not named. And typeclasses can define names that can be used across multiple types. Between all of these, it's much less painful than you might expect, though there certainly remains some pain.
  - tel 12y ago
    First, there are namespaces, it's just that they are associated with files instead of particular data types. Secondly, the naming issue only tends to become an issue when you have many types which all have similar internal structure. It turns out that, in Haskell at least, you can avoid needing this often by simply factoring out the shared structure (!). If this is not reasonable then there are boilerplate-y ways to use typeclasses for proper overloading (which also respects namespaces better than this solution does). Frankly, I have run into only one circumstance where I wanted to throw my computer through a wall due to record inefficiencies... and it only came up while trying to hand translate an the XML specification for ClinicalTrials.gov. It turns out there was a much simpler way to tackle the problem anyway.
jacquesm 12y ago
It sort of makes me wonder how much of the hype around Haskell is overblown, this seems like pretty basic stuff. Haskell has all kinds of interesting properties but the way it is presented is usually as though it is an end-run around just about every problem in other programming languages. A dose of up-front honesty about potential issues would be handy. Are there any other things that are problematic in Haskell that other programmers from lesser languages usually take for granted?
- tel 12y ago
  Eh, it's different. Nobody denies that. In practice I don't significantly care about the "record problem" in Haskell. It is a pain sometimes, but it is not so bad a pain to trade in complexity everywhere like one would have to to use one of these "batteries included" record replacements. As libraries they're alright.
- seagreen 12y ago
  I switched from Python and Go to Haskell over the last year. Haskell takes much longer to compile than Go and cabal hell can really suck. Other than that it's been absolutely fantastic.
  - jacquesm 12y ago
    What kind of programs do you write?
    - seagreen 12y ago
      For fun I'm attracted to various high-level information processing stuff and I do backend web dev at work. Haskell's definitely a Python replacement for me, I'm not writing any OSes in it.
    - codygman 12y ago
      Not the parent, but I made the same transition a couple of years ago. I emailed you something I've wrote in Haskell that might be relevant to you but didn't want to publicize too much yet.
pseudonom- 12y ago
The closest Python analogue is probably named tuples.

stingraycharles 12y ago

It's more like a struct from C.

ARussell 12y ago

It's essentially Haskell's version of a class, except Haskell isn't object-oriented. It holds data. So yes, you could view it as a dict, of sorts. Except each key in this dict/record generates a top-level function.

m_mueller 12y ago
How did having no namespaces in these things not become a massive headache for everyone? That would be the absolute killer argument for me to immediately switch to a different language if somehow possible.
- bodhi 12y ago
  > you cannot have two records share a field name in a single module (emphasis added.) I'm still a Haskell beginner, so I'm not the best person to comment on how this works out in practice.
- stingraycharles 12y ago
  So far it's more an inconvience -- in practice it doesn't surface that often, since modules represent the namespaces in Haskell. If you run into naming conflicts very often, chances are your modules are not isolated enough. You don't use records as often as you use classes in an OOP language, for example. Having said that, a lot of projects seem to have a general Types.hs where they declare all the types they share between modules. This is a great solution for that.
- mijoharas 12y ago
  My thoughts are that it is something of a headache, but the benefits of the language outweigh the pain-points, like this one, in many cases. I'd guess it's seen as one of the trade-offs you need to make for using a pure functional language. (I've yet to see many other languages with a type system as expressive as haskell).
- merijnv 12y ago
  The main reason it's not a massive headache is simple: Records aren't used THAT widely. Sure, in C++ or Java everything has named fields, because that's the only thing you have. Most Haskell datatypes use ADTs without record syntax, which means fields aren't named. Personally I only use records for large-ish "configuration" datatypes which and I just don't use that many of those for it to be a real problem.
- dons 12y ago
  Functions and lenses and module namespaces tend to alleviate the problem, not that it isn't annoying now and again. It does make some people go crazy though.
- dllthomas 12y ago
  It's not quite true that you have no namespaces. Rather, in most languages a class or struct creates a namespace. In Haskell, it does not. Record accessors are still constrained by module. There are also data types where the fields are not named. And typeclasses can define names that can be used across multiple types. Between all of these, it's much less painful than you might expect, though there certainly remains some pain.
- tel 12y ago
  First, there are namespaces, it's just that they are associated with files instead of particular data types. Secondly, the naming issue only tends to become an issue when you have many types which all have similar internal structure. It turns out that, in Haskell at least, you can avoid needing this often by simply factoring out the shared structure (!). If this is not reasonable then there are boilerplate-y ways to use typeclasses for proper overloading (which also respects namespaces better than this solution does). Frankly, I have run into only one circumstance where I wanted to throw my computer through a wall due to record inefficiencies... and it only came up while trying to hand translate an the XML specification for ClinicalTrials.gov. It turns out there was a much simpler way to tackle the problem anyway.

jacquesm 12y ago

It sort of makes me wonder how much of the hype around Haskell is overblown, this seems like pretty basic stuff. Haskell has all kinds of interesting properties but the way it is presented is usually as though it is an end-run around just about every problem in other programming languages. A dose of up-front honesty about potential issues would be handy. Are there any other things that are problematic in Haskell that other programmers from lesser languages usually take for granted?

tel 12y ago
Eh, it's different. Nobody denies that. In practice I don't significantly care about the "record problem" in Haskell. It is a pain sometimes, but it is not so bad a pain to trade in complexity everywhere like one would have to to use one of these "batteries included" record replacements. As libraries they're alright.
seagreen 12y ago
I switched from Python and Go to Haskell over the last year. Haskell takes much longer to compile than Go and cabal hell can really suck. Other than that it's been absolutely fantastic.
- jacquesm 12y ago
  What kind of programs do you write?
  - seagreen 12y ago
    For fun I'm attracted to various high-level information processing stuff and I do backend web dev at work. Haskell's definitely a Python replacement for me, I'm not writing any OSes in it.
  - codygman 12y ago
    Not the parent, but I made the same transition a couple of years ago. I emailed you something I've wrote in Haskell that might be relevant to you but didn't want to publicize too much yet.

pseudonom- 12y ago

The closest Python analogue is probably named tuples.