<div dir="ltr"><div style="font-family:monospace" class="gmail_default"><br>Hello Ron,<br><br>Thank you for your response!<br><br>> > I understand your point, but this requires me to apply<br>> > an ill fitting model because the language is unable to<br>> > map the one I actually need.<br>> <br>> But why did you decide that you need to do it *with<br>> records*? It’s not that the language isn’t able to<br>> represent the graph you want, but that you picked a<br>> language feature that is meant to represent tuples and<br>> you’re trying to use it to represent something that isn’t<br>> a tuple.<br>> <br>> Maybe you did it because you want to use pattern-matching<br>> and records have pattern-matching, but we would like to<br>> offer pattern-matching for other classes, too.<br><br>I actually have no issue going outside of records to do this. A final class with final public fields would meet my needs just as well. But neither that final class nor a record can get past this circular reference problem because Java does not allow a circular reference while maintaining immutability and direct reference.<br><br>By all means, if you can show me a well-fitting solution that accomplishes this with final classes WITHOUT dipping into indirection I've mentioned many times above or mutability (or reflection stuff), I'll take my metaphorical hat and go.<br><br>And I understand if that feels like an unreasonable request. I am actually of the opinion that it is an impossible request. But please, prove me wrong.<br><br>And as an aside, please take a look at Gavin's response. He points to another language that absolutely solved this problem. His F# example captures an example that meets all my needs for my representation.<br><br>> > Are you saying you can accomplish this without<br>> > indirection, as in without a Map lookup or something<br>> > equivalent? If so, please demonstrate.<br>> <br>> A set of pairs *is* a map (actually, a “multi map", i.e.<br>> a map from elements to sets). You could implement a map<br>> from just tuples (as students learn in an introductory FP<br>> course: you represent the map as a list, and the list is<br>> a linked list of item-tail pairs, i.e. a cons list) but<br>> you’re better off just using an existing map<br>> implementation.<br><br>And as I mentioned in a previous response, once you turn this from a set of nodes to a set of edges with a map lookup, you shoot clarity in the foot to get something that is possible. As I said, that solution works, but it 100% does not meet the indirection need I have been describing this entire time.<br><br>And if you recall from the last post, this Map lookup strategy that you are suggesting is the workaround I actually landed on, since it is the most effective of the ill-fitting solutions. But most effective does not make it a good fit.<br><br>> > Apologies, I was not clear here. My question to you is<br>> > actually, do you see a problem with the fact that<br>> > records cannot represent a circular reference to<br>> > themselves?<br>> <br>> No, because records are meant to represent tuples, and<br>> tuples don’t self-reference.<br>> <br>> > According to the definitions I cited earlier,<br>> > tuples/product types have circular references in their<br>> > domain of possible values<br>> <br>> They don’t. Let’s say that the product type T is defined<br>> as T := Integer x T. Then a tuple of type T can<br>> self-reference if and only if T (the second component)<br>> can self-reference. It’s perfectly consistent, therefore,<br>> for tuples to not self reference, and Java, like most<br>> languages with algebraic data types, says tuples don’t<br>> self-reference. You can’t construct a self-referencing<br>> instance of T because you’d need a component value that<br>> is the instance you’re constructing. It also ensures that<br>> recursions over values always terminate.<br><br>Ron, you're using circular logic to avoid the question.<br><br>My question was -- records currently cannot self-reference, do you think that is a problem?<br><br>You respond saying -- No, because records are tuples, and tuples cannot self-reference.<br><br>But when I challenge your definition of tuples, saying that they in fact CAN self-reference, you respond saying -- well, technically they can, but tuples in Java cannot because the requirement for self referencing is to contain a component that self-references, that component being the tuple type itself.<br><br>My entire question is asking, do you think it is a problem that records cannot self-reference, and you say no because records cannot self-reference, even though tuples can.<br><br>Please tell me you see how this is circular logic?<br><br>And finally, please look at Gavin's post here -- <a href="https://mail.openjdk.org/pipermail/amber-dev/2023-July/008142.html">https://mail.openjdk.org/pipermail/amber-dev/2023-July/008142.html</a><br><br>He has successfully provided an example of circular references that meets all the points I was talking about.<br><br>Thank you for your time and response!<br>David Alayachew<br></div><br></div>