5 ms·

>Context is not a requirement of the actual act of composition, though; that's what I'm trying to help you understand. Context might be why you might compose tw

>Context is not a requirement of the actual act of composition, though; that's what I'm trying to help you understand. Context might be why you might compose two things in a specific way, or why you might restrict composition between given things, but the act of composition itself is not tied to those specific requirements. In the functional realm: passing a function and list into a map function should work for any function and any list; map needn't care whether or not that function actually is applicable to that list (if it ain't, then that's the function's problem, not map's). Same deal for the "composeObject" function (if Foo and Bar shouldn't be composed, then don't try to compose Foo and Bar), and same deal for the compose procedure (if step1 and step6 shouldn't be composed, then don't try to compose step1 and step6). Context matters. This is what the type system is for, the type system makes it so the computer will also know what can compose with what. You claimed the computer doesn't care, the type system proves you wrong. >but the computer is still fully capable of composing things regardless of whether or not you think they should be composed. Composition as a concept itself doesn't exist as a command on the instruction set level. It's a higher level concept. Another higher level concept is teaching the computer about the domain by feeding it into the type system. Why are you talking about the low level inability of a computer to comprehend the domain when on that same level the computer is unable to compose things as well. The topic of conversation is about a higher level of logic. Types and composition allow your computer to know about domain and compose. >To humor your argument, though: Remember way back when i defined composition as a universal function? Meaning that the compose function should be able to compose ANYTHING. Not just a Foo and Bar and your arbitrary composition rule. For example it should be able to compose a ONE and a TWO into a THREE as well. That's my arbitrary composition rule for addition. Your example fails to prove anything nor humor anyone.

yellowapple 7y ago
> This is what the type system is for, the type system makes it so the computer will also know what can compose with what. But the computer doesn't have to know that in order for you to be able to compose things. You can compose things without a type system (or more precisely: with a type system where the only actual type is a machine-width word). You just have to take care to make sure the result makes sense in your domain (which a type system helps automate for you). That is: the type system is not the thing that lets you do composition. It's just the thing that lets you constrain what can be composed. In the pseudo-Forth example, you take two arbitrary procedures that pop arguments and push results, and you get back an arbitrary procedure that pops arguments and pushes results. Your ONE and TWO are now a THREE. They're fully interchangeable components (remember my suggestion of that word?). Whether you should interchange them is another story entirely, but you can if you want to. That's composition. > Remember way back when i defined composition as a universal function? Meaning that the compose function should be able to compose ANYTHING. That's exactly what the previous OO example did, but you complained that being able to compose anything somehow doesn't count as composition because it's not restrictive enough. Now you're complaining that not being able to compose anything somehow doesn't count as composition. Let's dig into what you might mean by that, though - specifically with your "arbitrary composition rule for addition". How would you go about implementing add(Store, Chicken) (or Store + Chicken)? What would that mean? What would your THREE actually be after adding your ONE and TWO? The normal answer would be using a bit of that "mortar and rebar" to tell the computer how to add a Chicken to a Store to get some other type (a Popeyes, perhaps?), e.g. by defining methods to polymorphically perform that addition, but it seems like you ain't exactly satisfied by that answer. Unfortunately, the type system alone doesn't really help you much here; just because the computer knows what a Chicken and a Store and a Popeyes is doesn't mean it knows how to add a Chicken and a Store to get a Popeyes. If you object to the "nonsensical" results of trying to add a Store to a Chicken, then you can't get around having to define specific implementations of that composition between a Store and a Chicken. Maybe you can cheat through it a bit by subclassing them from a common ancestor or having them both implement an interface and then add against that ancestor/interface, but that just punts the problem.
- crimsonalucard 7y ago
  >You can compose things without a type system Compose an array of strings with an integer. What do you get? Run time error OR type error. Please don't make up an arbitrary definition of composition as a counter example. These things generally don't compose unless you make up some definition on the spot. >You just have to take care to make sure the result makes sense in your domain (which a type system helps automate for you). Thanks for retelling me what I've been telling you since the beginning. > That's exactly what the previous OO example did, but you complained that being able to compose anything somehow doesn't count as composition because it's not restrictive enough. Now you're complaining that not being able to compose anything somehow doesn't count as composition. You don't get it. It should compose anything under a single rule of composition WITH CONTEXT. You are defining an arbitrary compose for a specific pair of types that keeps context but this definition of composition will fail with every other instance of any primitive outside of the Foo and Bar type. >Let's dig into what you might mean by that, though - specifically with your "arbitrary composition rule for addition". How would you go about implementing add(Store, Chicken) (or Store + Chicken)? What would that mean? What would your THREE actually be after adding your ONE and TWO? You're asking me? LOL. I'm actually the one asking YOU. I'm telling you that it's NOT POSSIBLE to compose things this way for objects and procedures. you're claiming it is. Let me state this as specifically as possible. Compose two THINGS under a universal DEFINITION with correct CONTEXT is what I'm talking about. Meaning a function that can compose cooking and ingredients into food can also compose eggs and sugar into a cookie while maintaining knowledge about what a cookie is, and what food is. Additionally, I am SAYING such a compose function for objects or procedures as parameters with OR without a type system CANNOT BE done. >but it seems like you ain't exactly satisfied by that answer. Unfortunately, the type system alone doesn't really help you much here; just because the computer knows what a Chicken and a Store and a Popeyes is doesn't mean it knows how to add a Chicken and a Store to get a Popeyes. Yeah I'm not satisfied with your answers. I'm satisfied with A answer that you don't currently know about. It is definitely possible to compose two primitives with context and with no mortar or rebar under a universal compose function. Just not with objects or procedures as primitives. >If you object to the "nonsensical" results of trying to add a Store to a Chicken, then you can't get around having to define specific implementations of that composition between a Store and a Chicken. Maybe you can cheat through it a bit by subclassing them from a common ancestor or having them both implement an interface and then add against that ancestor/interface, but that just punts the problem The problem isn't adding these things together. It's impossible to add these things together. It's getting your computer to know what can be composed and what can't. Your computer should know that composing a chicken with a store doesn't make sense. Either way you're starting to see the full picture because it doesn't even make sense to compose two chickens without you making up an arbitrary definition. There is ONE primitive where you can do this type of composition. It also relies on parametric polymorphism so in general you can't compose all these primitives together, only primitives of relevant context. Primitives of relevant contexts will compose to form higher order abstractions with contexts that make sense under a SINGLE definition. If you build your entire program using nothing but composing this primitive then every atom of your program is legos. Modular, reusable, refactorable, scalable. Powerful.

yellowapple 7y ago

> This is what the type system is for, the type system makes it so the computer will also know what can compose with what. But the computer doesn't have to know that in order for you to be able to compose things. You can compose things without a type system (or more precisely: with a type system where the only actual type is a machine-width word). You just have to take care to make sure the result makes sense in your domain (which a type system helps automate for you). That is: the type system is not the thing that lets you do composition. It's just the thing that lets you constrain what can be composed. In the pseudo-Forth example, you take two arbitrary procedures that pop arguments and push results, and you get back an arbitrary procedure that pops arguments and pushes results. Your ONE and TWO are now a THREE. They're fully interchangeable components (remember my suggestion of that word?). Whether you should interchange them is another story entirely, but you can if you want to. That's composition. > Remember way back when i defined composition as a universal function? Meaning that the compose function should be able to compose ANYTHING. That's exactly what the previous OO example did, but you complained that being able to compose anything somehow doesn't count as composition because it's not restrictive enough. Now you're complaining that not being able to compose anything somehow doesn't count as composition. Let's dig into what you might mean by that, though - specifically with your "arbitrary composition rule for addition". How would you go about implementing add(Store, Chicken) (or Store + Chicken)? What would that mean? What would your THREE actually be after adding your ONE and TWO? The normal answer would be using a bit of that "mortar and rebar" to tell the computer how to add a Chicken to a Store to get some other type (a Popeyes, perhaps?), e.g. by defining methods to polymorphically perform that addition, but it seems like you ain't exactly satisfied by that answer. Unfortunately, the type system alone doesn't really help you much here; just because the computer knows what a Chicken and a Store and a Popeyes is doesn't mean it knows how to add a Chicken and a Store to get a Popeyes. If you object to the "nonsensical" results of trying to add a Store to a Chicken, then you can't get around having to define specific implementations of that composition between a Store and a Chicken. Maybe you can cheat through it a bit by subclassing them from a common ancestor or having them both implement an interface and then add against that ancestor/interface, but that just punts the problem.

crimsonalucard 7y ago
>You can compose things without a type system Compose an array of strings with an integer. What do you get? Run time error OR type error. Please don't make up an arbitrary definition of composition as a counter example. These things generally don't compose unless you make up some definition on the spot. >You just have to take care to make sure the result makes sense in your domain (which a type system helps automate for you). Thanks for retelling me what I've been telling you since the beginning. > That's exactly what the previous OO example did, but you complained that being able to compose anything somehow doesn't count as composition because it's not restrictive enough. Now you're complaining that not being able to compose anything somehow doesn't count as composition. You don't get it. It should compose anything under a single rule of composition WITH CONTEXT. You are defining an arbitrary compose for a specific pair of types that keeps context but this definition of composition will fail with every other instance of any primitive outside of the Foo and Bar type. >Let's dig into what you might mean by that, though - specifically with your "arbitrary composition rule for addition". How would you go about implementing add(Store, Chicken) (or Store + Chicken)? What would that mean? What would your THREE actually be after adding your ONE and TWO? You're asking me? LOL. I'm actually the one asking YOU. I'm telling you that it's NOT POSSIBLE to compose things this way for objects and procedures. you're claiming it is. Let me state this as specifically as possible. Compose two THINGS under a universal DEFINITION with correct CONTEXT is what I'm talking about. Meaning a function that can compose cooking and ingredients into food can also compose eggs and sugar into a cookie while maintaining knowledge about what a cookie is, and what food is. Additionally, I am SAYING such a compose function for objects or procedures as parameters with OR without a type system CANNOT BE done. >but it seems like you ain't exactly satisfied by that answer. Unfortunately, the type system alone doesn't really help you much here; just because the computer knows what a Chicken and a Store and a Popeyes is doesn't mean it knows how to add a Chicken and a Store to get a Popeyes. Yeah I'm not satisfied with your answers. I'm satisfied with A answer that you don't currently know about. It is definitely possible to compose two primitives with context and with no mortar or rebar under a universal compose function. Just not with objects or procedures as primitives. >If you object to the "nonsensical" results of trying to add a Store to a Chicken, then you can't get around having to define specific implementations of that composition between a Store and a Chicken. Maybe you can cheat through it a bit by subclassing them from a common ancestor or having them both implement an interface and then add against that ancestor/interface, but that just punts the problem The problem isn't adding these things together. It's impossible to add these things together. It's getting your computer to know what can be composed and what can't. Your computer should know that composing a chicken with a store doesn't make sense. Either way you're starting to see the full picture because it doesn't even make sense to compose two chickens without you making up an arbitrary definition. There is ONE primitive where you can do this type of composition. It also relies on parametric polymorphism so in general you can't compose all these primitives together, only primitives of relevant context. Primitives of relevant contexts will compose to form higher order abstractions with contexts that make sense under a SINGLE definition. If you build your entire program using nothing but composing this primitive then every atom of your program is legos. Modular, reusable, refactorable, scalable. Powerful.