Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.


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.


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.


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.


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.


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.


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).


> 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.


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: