
I think I've solved the Haskell records problem - nikita-volkov
http://nikita-volkov.github.io/record/
======
stingraycharles
For the uninitiated, this solves a major (major!!) pain in the Haskell
community: the lack of namespacing. If you declare two records with an 'id'
field in the same module, you would get conflicts. People have been either
using prefixing (fooId and barId) or splitting up modules to solve this
problem, which can both considered to be ugly hacks.

I am so glad the author has been able to pull this off, and it is one of those
"why didnt anybody think of this before, it is so obvious!" moments.

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

~~~
jacquesm
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?

~~~
seagreen
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
What kind of programs do you write?

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

~~~
jacquesm
Thank you very much! I'm right now hip deep in Erlang and I very much would
like to have a better look at Haskell.

~~~
jerf
Then you'll want to see also Cloud Haskell: [http://haskell-
distributed.github.io/](http://haskell-distributed.github.io/)

I'm not sure exactly what its current status is in terms of production-
readiness but I believe it is still very active. The GitHub repos seem to be
chugging along.

~~~
jacquesm
Thanks!

~~~
mintplant
Not to bombard you with too much at once, but one interesting CloudHaskell-
related extension that's landing in GHC 7.10 is Static Pointers: safe
references to "static" code (constant values, functions, etc.) that can be
passed between running instances of a program.

[https://ocharles.org.uk/blog/guest-
posts/2014-12-23-static-p...](https://ocharles.org.uk/blog/guest-
posts/2014-12-23-static-pointers.html)

------
conistonwater
Isn't this solved (or addressed) by OverloadedRecordFields in GHC 7.10?

[https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedReco...](https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields)

[https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedReco...](https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/Design)

~~~
tmhedberg
Sadly, OverloadedRecordFields won't be making it into 7.10.

~~~
mijoharas
That's a shame, do we know why? is it just not finished being implemented? I
found a page[0] that said at some point they had stalled on refactoring
something.

[0]
[https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedReco...](https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/Implementation#Currentstatus)

~~~
tmhedberg
There's some info here:
[http://www.reddit.com/r/haskell/comments/2pnjdk/is_overloade...](http://www.reddit.com/r/haskell/comments/2pnjdk/is_overloadedrecordfields_getting_it_into_7101/).

tl;dr: The patch worked but was messy/overly complex, so it needs refactoring
before it's merged.

~~~
kxyvr
That's a shame and the first I've heard of the delay. For me and the software
that I write, this is a must have feature and I was very much looking forward
to its release.

------
ximeng
Nice article.

Could anyone comment on this:

"Haskell syntax parsing needs to be reimplemented in the “record” library"

That sounds like a big, unending task. How hard would it be for this to be
implemented as an actual Haskell feature, without quasi-quoting etc.?

~~~
tel
It'd be a consensus thing more than anything else. I for one am not sure that
this is a sufficiently correct feature to implement in language.

But that said, Haskell's LANGUAGE extension system does allow things like this
to be easily added to the language in a smooth way.

~~~
ximeng
It does look like a pretty clean implementation, I find myself wondering what
the downsides are given all the positive comments in the article.

------
yummyfajitas
It seems to me that most of these issues could be solved at the syntactic
level simply by allowing recordval.fieldname syntax. I truly don't understand
why Haskell doesn't allow this - anyone have some insight?

~~~
gregwebs
This has been proposed, and it is still a good idea if one wants to make
Haskell accessible to OO programers. It would require the function composition
dot to have spaces around it, which is already fairly standard practice.

However, just adding some syntax does not finish solving the problem: one
still needs to figure out how to get everything to typecheck under all use
cases (and all type extensions) and also to operate efficiently at runtime.
This article does that (although it isn't actually explained that well in the
article).

~~~
FreeFull
The . already has whitespace-sensitive use for namespacing in Haskell, for
example `Data.List.concat` is parsed differently from `Data . List . concat`

------
eru
And I thought lenses were the canonical solution by now?

EDIT: Reading the article a second time enlightened me.

------
millstone
What's a "quasi-quoter?"

~~~
a-saleh
It is a way to create embedded DSLs in haskell.

If I understand correctly, when haskell compiler sees [foo|some dsl language
inside|] it knows, that it should use parser asigned to foo on string inside
of quasi-quotes.

Long time ago, I tried learning this using this tutorial
[http://quasimal.com/posts/2012-05-25-quasitext-and-
quasiquot...](http://quasimal.com/posts/2012-05-25-quasitext-and-
quasiquoting.html)

------
slashnull
String typing to the rescue!

~~~
eru
Isn't this closer to `string-kinding'?

~~~
slashnull
Mhyes, it appears that I misunderstood the precise mechanism of this lib.

I don't know how to feel about the use of template Haskell in this lib (beyond
the fact that it seems like it works great and avoids the curse of the weird
error messages). I'm tempted to see it as a proof that, while deconstructive
pattern matching is great (I really mean it!), it's nearly impossible to get
rid of antediluvian dot accessor syntax/semantics.

Either way I'm too tired and incompetent with Haskell to have a meaningful
opinion on that.

------
pekk
I think I have a radical idea: use a language which solves this problem by
design from the beginning. Much simpler.

~~~
nikita-volkov
There is a problem. I know no other language, which manages to have at the
same a type system as powerful, abstractions as insightful, as good a support
for concurrency and parallel programming, an ecosystem as rich and which
performs as well.

Usable records are just an icing on the cake, but it's the cake that matters.

~~~
eru
Another way to solve this problem, is to allow multiple (nested) modules per
file. A bit like OCaml. Then standard Haskell-syntax can already handle
everything we need.

~~~
tel
This would work but run a bit afoul of global instance canonicity.

~~~
evincarofautumn
How so? I think they mean as a syntactic feature, not having parameterised
modules.

~~~
tel
What happens if you define an instance inside of a nested module? When does it
become available?

~~~
dllthomas
I'd like to just see a per-project uniqueness check on used instances.

