3 ms·

> It's only violating your idiosyncratic insistence that there can only be one in-memory representation of any immutable value. I never said this! There can be

> It's only violating your idiosyncratic insistence that there can only be one in-memory representation of any immutable value. I never said this! There can be multiple representations of the same value. For example, the same ordered set may be represented as two distinct red-black trees, balanced differently. Values are different from their memory representations. Different memory representations of the same value are okay. Branching on the difference is not. Of course, to hide representation differences from users, you need abstract data types [0], and, sadly, Python doesn't have these. [0] https://www.cs.cmu.edu/~rwh/introsml/modules/sigstruct.htm https://www.cs.cmu.edu/~rwh/introsml/modules/sigstruct.htm > If you want to argue that Python ought to change its implementation to guarantee that, for example, any two references to the tuple (1, 2, 3) must refer to the same in-memory representation (so the 'is' operator would always return True), because that would save memory, or make the runtime faster, or whatever, that's fine. I never said this either. I said that it should be a valid optimization, not that implementations absolutely have to do it. As things stand now, it's not a valid optimization, because it would break existing programs. In actuality, I don't care much about the optimization itself. However, it's a good benchmark for assessing whether Python has compound values. Values can be deduplicated, because they may be represented more than once. Objects can't be deduplicated, because by definition an object exists exactly once in memory. > But trying to claim that Python is violating "one of the cornerstones of Western logic" is just too much. It seems appropriate to me. But, to be clear, what I was claiming violates the indiscernibility of identicals is dragonwriter's explanation, not Python itself. A simple explanation that doesn't violate the indiscernibility of identicals is to admit that Python doesn't have compound values. Which takes us back to square one [1]. [1] https://news.ycombinator.com/item?id=12358968 https://news.ycombinator.com/item?id=12358968

pdonis 10y ago
> I never said this! As Rhett Butler said to Scarlett O'Hara, you gave a very good imitation. > Different memory representations of the same value are okay. Branching on the difference is not. Branching on a difference other than a difference in logical identity, if you are intending to test for logical identity, is obviously an error. The fix for that in Python is simple: if you want to test for logical identity, use the == operator. 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. Maybe you've never had occasion to do that in programs you write, but others might. > I said that it should be a valid optimization Consider my comment suitably modified. The rest of what I said still stands: there are tradeoffs involved, and reasonable people can differ on where the tradeoff ends up. You have one opinion; the Python developers have another. That doesn't mean the Python developers are violating Western logic. > what I was claiming violates the indiscernibility of identicals is dragonwriter's explanation, not Python itself. A simple explanation that doesn't violate the indiscernibility of identicals is to admit that Python doesn't have compound values. And to me this is a distinction without a difference. Nothing is stopping you from defining "compound values" so that a Python tuple isn't a compound value. But nothing is stopping the rest of us from not caring about your definition. Which, as you say, takes us back to square one. What would be helpful is if you could give some reason why your definition of compound values is so important, other than talking about identity of indiscernibles and violating Western logic. What makes a language that allows compound values, by your definition, better than a language that doesn't? And if your only answer (other than preserving Western logic) is "better runtime efficiency" (less memory, faster operations), then it seems to me you would do much better to make that argument directly, instead of cloaking it with all this talk about "compound values". But maybe that's just me.
- catnaroek 10y ago
  > 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?
dragonwriter 10y ago
> > It's only violating your idiosyncratic insistence that there can only be one in-memory representation of any immutable value. > I never said this! The standards you have set require either (1) That there is only one in-memory representation of a given value, or (2) The language has no facilities that allow you to inquire about the in-memory representation used by a particular reference to a value.
- catnaroek 10y ago
  > That there is only one in-memory representation of a given value, or No. > The language has no facilities that allow you to inquire about the in-memory representation used by a particular reference to a value. s/reference to// , otherwise yes.
- deleted 10y ago
  [deleted]

pdonis 10y ago

> I never said this! As Rhett Butler said to Scarlett O'Hara, you gave a very good imitation. > Different memory representations of the same value are okay. Branching on the difference is not. Branching on a difference other than a difference in logical identity, if you are intending to test for logical identity, is obviously an error. The fix for that in Python is simple: if you want to test for logical identity, use the == operator. 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. Maybe you've never had occasion to do that in programs you write, but others might. > I said that it should be a valid optimization Consider my comment suitably modified. The rest of what I said still stands: there are tradeoffs involved, and reasonable people can differ on where the tradeoff ends up. You have one opinion; the Python developers have another. That doesn't mean the Python developers are violating Western logic. > what I was claiming violates the indiscernibility of identicals is dragonwriter's explanation, not Python itself. A simple explanation that doesn't violate the indiscernibility of identicals is to admit that Python doesn't have compound values. And to me this is a distinction without a difference. Nothing is stopping you from defining "compound values" so that a Python tuple isn't a compound value. But nothing is stopping the rest of us from not caring about your definition. Which, as you say, takes us back to square one. What would be helpful is if you could give some reason why your definition of compound values is so important, other than talking about identity of indiscernibles and violating Western logic. What makes a language that allows compound values, by your definition, better than a language that doesn't? And if your only answer (other than preserving Western logic) is "better runtime efficiency" (less memory, faster operations), then it seems to me you would do much better to make that argument directly, instead of cloaking it with all this talk about "compound values". But maybe that's just me.

catnaroek 10y ago
> 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?

dragonwriter 10y ago

> > It's only violating your idiosyncratic insistence that there can only be one in-memory representation of any immutable value. > I never said this! The standards you have set require either (1) That there is only one in-memory representation of a given value, or (2) The language has no facilities that allow you to inquire about the in-memory representation used by a particular reference to a value.

catnaroek 10y ago
> That there is only one in-memory representation of a given value, or No. > The language has no facilities that allow you to inquire about the in-memory representation used by a particular reference to a value. s/reference to// , otherwise yes.
deleted 10y ago
[deleted]