3 ms·

> Branching on a difference other than a difference in logical identity, if you're interested in a difference other than a difference in logical identity, is pe

> Branching on a difference other than a difference in logical identity, if you're interested in a difference other than a difference in logical identity, is perfectly reasonable. It's unreasonable to have a finer-grained distinction than logical identity. If two things are the same, they are the same. If they are not, well, they are not. Again, tautologies! > That doesn't mean the Python developers are violating Western logic. I never said Python developers are violating Western logic. I said dragonwriter's explanation of how so-called “compound values” work in Python is inconsistent with Western logic. I have an explanation of how Python works that's consistent with it, but it requires rejecting the assumption that Python has compound values. > Nothing is stopping you from defining "compound values" so that a Python tuple isn't a compound value. The definition of compound value is simple: a value that you can tear apart into its constituent parts, then reassemble, getting the original value. You can't get the original tuple object by creating a new tuple object with the original tuple's components. The `is` operator will brush the difference on your face. > What makes a language that allows compound values, by your definition, better than a language that doesn't? The easiest way to reason about programs that's completely rigorous (i.e., not just testing on a couple sample inputs) is equational reasoning, which is basically showing that two syntactically different expressions evaluate to the same value. (For example, one expression might be an obviously correct but unacceptably inefficient program, and the other expression might be the program you actually intend to deliver.) In practice, realistic problem domain have to be modeled using compound entities (values or objects), so if you want to use equational reasoning, you need compound values.

pdonis 10y ago
> It's unreasonable to have a finer-grained distinction than logical identity. Maybe to you. Not to me. And not, I suspect, to most of the other programmers in this discussion. > The definition of compound value is simple Your definition. Why should I care? See below. > if you want to use equational reasoning, you need compound values. Ok, so this would mean that, according to you, it is impossible to use equational reasoning with Python programs. Whereas, according to me, it is only impossible to do this with Python programs that use mutable objects (where "mutable" here includes tuples whose slots point to mutable objects). And of course this wouldn't just apply to Python; the general distinction here could be drawn, in principle, in any language. Or even independently of choosing a language. So I have another tradeoff here: I can use mutable objects, which can make programs easier to write, but then I can't reason rigorously about them; or I can restrict myself to immutable objects (which means that any time I would have mutated an object writing programs the other way, I instead have to construct a new immutable object with the same logical properties that the mutated object would have had), which makes programs harder to write, but allows me to reason rigorously about them. Can you show me any real-world examples where using the latter programming style has paid dividends?
- catnaroek 10y ago
  > Ok, so this would mean that, according to you, it is impossible to use equational reasoning with Python programs. You can use equational reasoning on the values that Python actually gives you: small numbers, special constants and object references. > Whereas, according to me, it is only impossible to do this with Python programs that use mutable objects (where "mutable" here includes tuples whose slots point to mutable objects). You can in principle use equational reasoning on programs that manipulate mutable objects. What you can't do is treat two distinct objects as equal. But, of course, in practice, you can do whatever you want. Whether your reasoning is sound is a-whole-nother matter. > I instead have to construct a new immutable object with the same logical properties that the mutated object would have had), which makes programs harder to write, but allows me to reason rigorously about them. No, this would be wrong. You can't use equational reasoning on objects themselves. You can only use equational reasoning on values. The value itself might be a program that manipulates objects, but you can't equate two distinct objects.
  - pdonis 10y ago
    > You can't use equational reasoning on objects themselves. I didn't say you could. I said you could use equational reasoning on programs that only manipulate immutable objects. "Immutable" means that the object's value can never change, so you can substitute the object's value for the object itself everywhere it appears in the program. Then you can apply equational reasoning to the values so obtained. In the particular case I described, you would end up using equational reasoning on the value transformation implemented by the code that constructs the new immutable object. You would obtain that transformation, as above, by substituting object values for objects in the syntactic statement of the code. > You can in principle use equational reasoning on programs that manipulate mutable objects. How do you reason using an object's value if that value can change?
    - catnaroek 10y ago
      > "Immutable" means that the object's value can never change, so you can substitute the object's value for the object itself everywhere it appears in the program. No, you can't. Immutable objects still have physical identities. If you want to do equational reasoning, you need to get a hold of the value itself. > How do you reason using an object's value if that value can change? Objects don't have “values”, they have “states”. And I said you can reason about programs that manipulate objects, not about the states of these objects. (Though maybe in a few special cases you can do the latter too.)

pdonis 10y ago

> It's unreasonable to have a finer-grained distinction than logical identity. Maybe to you. Not to me. And not, I suspect, to most of the other programmers in this discussion. > The definition of compound value is simple Your definition. Why should I care? See below. > if you want to use equational reasoning, you need compound values. Ok, so this would mean that, according to you, it is impossible to use equational reasoning with Python programs. Whereas, according to me, it is only impossible to do this with Python programs that use mutable objects (where "mutable" here includes tuples whose slots point to mutable objects). And of course this wouldn't just apply to Python; the general distinction here could be drawn, in principle, in any language. Or even independently of choosing a language. So I have another tradeoff here: I can use mutable objects, which can make programs easier to write, but then I can't reason rigorously about them; or I can restrict myself to immutable objects (which means that any time I would have mutated an object writing programs the other way, I instead have to construct a new immutable object with the same logical properties that the mutated object would have had), which makes programs harder to write, but allows me to reason rigorously about them. Can you show me any real-world examples where using the latter programming style has paid dividends?

catnaroek 10y ago
> Ok, so this would mean that, according to you, it is impossible to use equational reasoning with Python programs. You can use equational reasoning on the values that Python actually gives you: small numbers, special constants and object references. > Whereas, according to me, it is only impossible to do this with Python programs that use mutable objects (where "mutable" here includes tuples whose slots point to mutable objects). You can in principle use equational reasoning on programs that manipulate mutable objects. What you can't do is treat two distinct objects as equal. But, of course, in practice, you can do whatever you want. Whether your reasoning is sound is a-whole-nother matter. > I instead have to construct a new immutable object with the same logical properties that the mutated object would have had), which makes programs harder to write, but allows me to reason rigorously about them. No, this would be wrong. You can't use equational reasoning on objects themselves. You can only use equational reasoning on values. The value itself might be a program that manipulates objects, but you can't equate two distinct objects.
- pdonis 10y ago
  > You can't use equational reasoning on objects themselves. I didn't say you could. I said you could use equational reasoning on programs that only manipulate immutable objects. "Immutable" means that the object's value can never change, so you can substitute the object's value for the object itself everywhere it appears in the program. Then you can apply equational reasoning to the values so obtained. In the particular case I described, you would end up using equational reasoning on the value transformation implemented by the code that constructs the new immutable object. You would obtain that transformation, as above, by substituting object values for objects in the syntactic statement of the code. > You can in principle use equational reasoning on programs that manipulate mutable objects. How do you reason using an object's value if that value can change?
  - catnaroek 10y ago
    > "Immutable" means that the object's value can never change, so you can substitute the object's value for the object itself everywhere it appears in the program. No, you can't. Immutable objects still have physical identities. If you want to do equational reasoning, you need to get a hold of the value itself. > How do you reason using an object's value if that value can change? Objects don't have “values”, they have “states”. And I said you can reason about programs that manipulate objects, not about the states of these objects. (Though maybe in a few special cases you can do the latter too.)