4 ms·

>Yes! But more broadly about composition in general. Functional programming in general is not about data composition. There is a difference between function co

>Yes! But more broadly about composition in general. Functional programming in general is not about data composition. There is a difference between function composition and data composition in FP. Function composition produces a new type given two separate types. In your example the type is the same. In Haskell if you wanted to do data composition, you would need something like dependent types or some rudimentary form of it. If such a thing was invented, it may look something like this: a -> b -> (a * b) where a and b can be records or "structs" and (a + b) is the composed record. This type signature preserves the notion of parametric polymorphism in function composition which looks like this: (a -> b) -> (c -> a) -> (c -> b) I'm no expert but as far as I know, in Haskell a new type must be defined manually when composing data but not when composing functions. The tuple type actually shares an isomorphism with the concepts I am describing above. However it ascribes a sort of "order" on the types and feels more like a container of two types than it does a composition of types. I will illustrate below: a -> b -> (a,b) != a -> b -> (b,a) a -> b -> (a * b) == a -> b -> (b * a) The ECS pattern among gaming focuses on the data problem you describe but largely suffers from the same issue as it is limited by the type system.

sfvisser 7y ago
It's very easy to compose data in Haskell. data Expr = Const Int | Add Expr Expr | Mul Expr Expr myExpr = Mul (Add (Const 1 2)) 4 > There is a difference between function composition and data composition in FP. The difference is rather blurry, because data constructors are very much like functions. > Function composition produces a new type given two separate types. Yes and no. The type might look different, but it's still a function! You can change the function domain to something else (like a DB query) to better see how this is actually type-preserving in a meaningful way: Query a b -> Query c a -> Query c b Yes, the parameter types are different, but that's what makes this so powerful.
- crimsonalucard 7y ago
  >Yes and no. The type might look different, but it's still a function! The type is different. Functions are a class of types. The output of function composition is absolutely a different type but within the class of function types. >It's very easy to compose data in Haskell. I suggest you reread my post, I do not believe you fully understood it. You can compose data in ALL languages. >Query a b -> Query c a -> Query c b I mentioned the tuple type in my post which is essentially the same thing as what you're doing sans the constructor. In type theory these things are called "Product types." Products are commutative, but in Haskell Data composition does not hold this property. See below: (a,b) != (b,a) Query a b != Query b a while (a * b) == (b * a) I am saying there is limited power in Data composition in Haskell, it is not as "complete" as function composition. It also brings nothing new to the table as the data compositional patterns are used outside of FP extensively.
  - sfvisser 7y ago
    > The type is different. Functions are a class of types. The output of function composition is absolutely a different type but within the class of function types. I know how types and type constructors work, it's completely irrelevant in the context of what I was trying to say about composition in FP. It seems to me you're probably talking about a very specific technical form of composition. I'm not. To me a simple function like `vertically :: [Ui] -> Ui` is also about composition. The input and output types of the `vertically` function are not the same no, but informally we're still composing UIs into UIs. Which is exactly the level of detail I care for in this discussion.
    - crimsonalucard 7y ago
      Types can be composed in two ways. This is fundamental to type theory. It can be composed via a product or a sum.
    - gowld 7y ago
      Almost Every language has data composition if all you mean is "it's possible to wrap two things in a container" or "you can apply a function to two things and get a third thing".

sfvisser 7y ago

It's very easy to compose data in Haskell. data Expr = Const Int | Add Expr Expr | Mul Expr Expr myExpr = Mul (Add (Const 1 2)) 4 > There is a difference between function composition and data composition in FP. The difference is rather blurry, because data constructors are very much like functions. > Function composition produces a new type given two separate types. Yes and no. The type might look different, but it's still a function! You can change the function domain to something else (like a DB query) to better see how this is actually type-preserving in a meaningful way: Query a b -> Query c a -> Query c b Yes, the parameter types are different, but that's what makes this so powerful.

crimsonalucard 7y ago
>Yes and no. The type might look different, but it's still a function! The type is different. Functions are a class of types. The output of function composition is absolutely a different type but within the class of function types. >It's very easy to compose data in Haskell. I suggest you reread my post, I do not believe you fully understood it. You can compose data in ALL languages. >Query a b -> Query c a -> Query c b I mentioned the tuple type in my post which is essentially the same thing as what you're doing sans the constructor. In type theory these things are called "Product types." Products are commutative, but in Haskell Data composition does not hold this property. See below: (a,b) != (b,a) Query a b != Query b a while (a * b) == (b * a) I am saying there is limited power in Data composition in Haskell, it is not as "complete" as function composition. It also brings nothing new to the table as the data compositional patterns are used outside of FP extensively.
- sfvisser 7y ago
  > The type is different. Functions are a class of types. The output of function composition is absolutely a different type but within the class of function types. I know how types and type constructors work, it's completely irrelevant in the context of what I was trying to say about composition in FP. It seems to me you're probably talking about a very specific technical form of composition. I'm not. To me a simple function like `vertically :: [Ui] -> Ui` is also about composition. The input and output types of the `vertically` function are not the same no, but informally we're still composing UIs into UIs. Which is exactly the level of detail I care for in this discussion.
  - crimsonalucard 7y ago
    Types can be composed in two ways. This is fundamental to type theory. It can be composed via a product or a sum.
  - gowld 7y ago
    Almost Every language has data composition if all you mean is "it's possible to wrap two things in a container" or "you can apply a function to two things and get a third thing".