5 ms·

After many years of struggling with Haskell, I've all but given up on it, because of the broken record semantics. They seem to be able to find time to implement

After many years of struggling with Haskell, I've all but given up on it, because of the broken record semantics. They seem to be able to find time to implement monad comprehensions or whatever paper fodder is most in vogue, but you still can't have two datatypes with the same field name in the same module. It's not a serious language.

issaria 11y ago
A record field accessor is just a normal function, are you also expecting define methods with the same name within the same module? If you want an elegant solution, write a typeclass. You have to write you java in the haskell way. https://wiki.haskell.org/Name_clashes_in_record_fields https://wiki.haskell.org/Name_clashes_in_record_fields
elihu 11y ago
That is also true of Ocaml, and probably every other ML derived language that treats accessor functions as ordinary functions (rather than using the C-style dot operator). There is a type-directed name resolution proposal that would remove this limitation in Haskell, but it would probably make the typechecker a lot more complicated. The can't-reuse-field-names thing is annoying, but claiming that it "isn't a serious language" because they made a design choice that doesn't meet your exact expectations seems kind of closed-minded to me.
- kuschku 11y ago
  Or one could use the lisp-way – and just call the functions <record-name>-<field-name>. This avoids those problems.
  - gmfawcett 11y ago
    The Ocaml way would be to define the functions in separate modules (A.foo, B.foo, etc.). There are convenient syntaxes for declaring which modules are in scope in a given expression, as well as support for first-class modules (you can define functions that take modules as parameters). The module system is sophisticated, and is arguably the "power feature" of Ocaml.
  - creichert 11y ago
    This is what you generally see in larger haskell programs which might have a name clash (at least it's what I use): data F = F { fName :: String } data P = P { pName :: String }
    - LeonidasXIV 11y ago
      Yes, this is one of the cases where ML modules are elegant, since you can put the definition of the type into its own module, so it becomes F.t and P.t and you avoid field name clashes.
- pcwalton 11y ago
  > ML derived language that treats accessor functions as ordinary functions OCaml is not in that tradition—field projection uses dot notation and has historically not been an ordinary function (although maybe that has changed in later versions).
  - gmfawcett 11y ago
    You're right, and that is still the case.
- lpw25 11y ago
  OCaml has had type-directed record disambiguation for a few versions now. So you can quite easily reuse field names these days.
  - elihu 11y ago
    That's cool, I didn't realize they had done that. I haven't used Ocaml in quite awhile -- it's good to hear the language is still getting better.
djur 11y ago
Having two datatypes with the same field name in scope doesn't work well with type inference. OCaml permits it, but it requires type annotations, and in practice it seems like developers solve the problem the same way Haskell does -- separate modules. That said, working with modules is a lot nicer in OCaml than in Haskell, so it's a less painful solution.

issaria 11y ago

A record field accessor is just a normal function, are you also expecting define methods with the same name within the same module? If you want an elegant solution, write a typeclass. You have to write you java in the haskell way. https://wiki.haskell.org/Name_clashes_in_record_fields https://wiki.haskell.org/Name_clashes_in_record_fields

elihu 11y ago

That is also true of Ocaml, and probably every other ML derived language that treats accessor functions as ordinary functions (rather than using the C-style dot operator). There is a type-directed name resolution proposal that would remove this limitation in Haskell, but it would probably make the typechecker a lot more complicated. The can't-reuse-field-names thing is annoying, but claiming that it "isn't a serious language" because they made a design choice that doesn't meet your exact expectations seems kind of closed-minded to me.

kuschku 11y ago
Or one could use the lisp-way – and just call the functions <record-name>-<field-name>. This avoids those problems.
- gmfawcett 11y ago
  The Ocaml way would be to define the functions in separate modules (A.foo, B.foo, etc.). There are convenient syntaxes for declaring which modules are in scope in a given expression, as well as support for first-class modules (you can define functions that take modules as parameters). The module system is sophisticated, and is arguably the "power feature" of Ocaml.
- creichert 11y ago
  This is what you generally see in larger haskell programs which might have a name clash (at least it's what I use): data F = F { fName :: String } data P = P { pName :: String }
  - LeonidasXIV 11y ago
    Yes, this is one of the cases where ML modules are elegant, since you can put the definition of the type into its own module, so it becomes F.t and P.t and you avoid field name clashes.
pcwalton 11y ago
> ML derived language that treats accessor functions as ordinary functions OCaml is not in that tradition—field projection uses dot notation and has historically not been an ordinary function (although maybe that has changed in later versions).
- gmfawcett 11y ago
  You're right, and that is still the case.
lpw25 11y ago
OCaml has had type-directed record disambiguation for a few versions now. So you can quite easily reuse field names these days.
- elihu 11y ago
  That's cool, I didn't realize they had done that. I haven't used Ocaml in quite awhile -- it's good to hear the language is still getting better.

djur 11y ago

Having two datatypes with the same field name in scope doesn't work well with type inference. OCaml permits it, but it requires type annotations, and in practice it seems like developers solve the problem the same way Haskell does -- separate modules. That said, working with modules is a lot nicer in OCaml than in Haskell, so it's a less painful solution.