5 ms·

Functions are data (and very cool data, too)

34 points by dons 17y ago

joe_the_user 17y ago
Doe sql injection count?
silentOpen 17y ago
What's the problem that is actually trying to be solved? The user of your implementation will inform the design choices you make. Using functions to represent objects like this is rather silly because they are opaque and only support a single operation. Here are a number of possibly better ways to do it: - Emulate objects with functions and messages like with scheme or lisp. - Use structural typing or polymorphic variants like in OCaml. - Use records with function fields. - Use a variant union. - Extend/build a list monad over your class. Can you think of other or better ways?
- deleted 17y ago
  [deleted]
Retric 17y ago
The OO approach would be to have a virtual function in the parent class and then use lists of the parent class type. Does Haskell prevent that from working, or is he just attacking the OO approach based on a bad OO design?
- twp 17y ago
  I'd argue that he's using a bad FP approach. He focuses on one aspect of shapes: testing whether a point is inside it or not. But this is far from a complete, usable representation. How do you draw a shape? Find its edge? Find its bounds? Convex hull? Transform? Test for convexity? Basically, the original post is just another newbie FP realising that - hey - if you're only every going to call one function of a class then the class is completely defined by that function. He presents a poor and incomplete solution. There are much better blog posts on FP design than this. Please don't upvote this one.
- kscaldef 17y ago
  Haskell types do not have an inheritance structure. Typeclasses do, however this still does not allow you to create a heterogeneous list. This is probably a bit terse, but you'd really be better off to go read an introduction to the Haskell type system than to have me try to explain it here.
- cia_plant 17y ago
  The OO approach is possible in Haskell using "existential types". However, this is an extension to the language which is rarely used. The more normal solution is to make a single data type which is a disjunction of all the shapes which you want to deal with.

34 points by dons 17y ago

Doe sql injection count?

What's the problem that is actually trying to be solved? The user of your implementation will inform the design choices you make. Using functions to represent objects like this is rather silly because they are opaque and only support a single operation. Here are a number of possibly better ways to do it: - Emulate objects with functions and messages like with scheme or lisp. - Use structural typing or polymorphic variants like in OCaml. - Use records with function fields. - Use a variant union. - Extend/build a list monad over your class. Can you think of other or better ways?

deleted 17y ago
[deleted]

Retric 17y ago

The OO approach would be to have a virtual function in the parent class and then use lists of the parent class type. Does Haskell prevent that from working, or is he just attacking the OO approach based on a bad OO design?

twp 17y ago
I'd argue that he's using a bad FP approach. He focuses on one aspect of shapes: testing whether a point is inside it or not. But this is far from a complete, usable representation. How do you draw a shape? Find its edge? Find its bounds? Convex hull? Transform? Test for convexity? Basically, the original post is just another newbie FP realising that - hey - if you're only every going to call one function of a class then the class is completely defined by that function. He presents a poor and incomplete solution. There are much better blog posts on FP design than this. Please don't upvote this one.
kscaldef 17y ago
Haskell types do not have an inheritance structure. Typeclasses do, however this still does not allow you to create a heterogeneous list. This is probably a bit terse, but you'd really be better off to go read an introduction to the Haskell type system than to have me try to explain it here.
cia_plant 17y ago
The OO approach is possible in Haskell using "existential types". However, this is an extension to the language which is rarely used. The more normal solution is to make a single data type which is a disjunction of all the shapes which you want to deal with.