> I have no idea you mean by that. The link you provided did not help. You can't define a type in Go whose instances are rectangles. If you define: type R

> I have no idea you mean by that. The link you provided did not help. You can't define a type in Go whose instances are rectangles. If you define: type Rectangle struct { Width, Height int } Then a so-called “Rectangle” is actually a mutable object whose current state is one rectangle, but whose state the very next moment might be another rectangle. > I'm sceptical about that. I am going to need an example of a LSP violations made with immutable types. I never said that ML violates the LSP. I said that it doesn't solve the rectangle-square problem. > I'm not sure what you are saying here. Does ML prevent the problem, or doesn't it? You seem to be saying that it doesn't. But according to Wikipedia, ML is type safe (for some definition of that term), and in your initial comment, you stated that type safe languages ensure adherence to LSP. ML adheres to the LSP trivially, because the language has no subtyping relation to begin with. Another way to view this is that every type has exactly one subtype: the type itself. Unfortunately, precisely because of this, it doesn't solve the rectangle-square problem. > Because I can get the address of it in Go? So what? That's hardly something you do by accident. And if your point is about what the language makes possible, rather than what it makes likely, I can't prove theorems about what a language makes “likely”. > I assure you that you can get in wrong in any language. The only difference is how much effort it requires. You can't take the address of a rectangle in ML. The only things that have physical identities are reference cells, and two physically distinct reference cells are always considered different values, even if their contents are the same. > In the Rectangle/Square example, calling setWidth() or setHeight() on a Square are perfectly alright as far as the Type system is concerned. What you're calling a “Square” is, as a matter of fact, not a square. > LSP is not about type errors: The symptoms of violating it are not that operations are performed on values that are not appropriate for values of that type. You are projecting your wants and desires (namely: a type of rectangles, a type of squares, and that the latter be a subtype of the former) onto the LSP, but the LSP doesn't care. The LSP only cares about the types the language actually gives you. The meaning of a type isn't in its name, but in what its instances actually do. > If the programmer had thought to specify -- using types -- that a Rectangle’s width and height should always be independently adjustable, Then the programmer doesn't know what a rectangle is. (Assuming you meant “adjustable using a setter”.)