<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">
Hi David,
<div><br>
</div>
<div>I think what you are asking for is “why can’t I build cyclic record values”? </div>
<div><br>
</div>
<div>This is a reasonable question - it’s a very common question in languages that are build to be immutable from the ground-up, e.g. functional languages. For these languages the solution is either to just add pointers (e.g Standard ML took this approach),
or to support something more first class. If you look at F#, you’ll see that they support this - although it’s pretty hidden in the spec! They allow (i) let expressions to be recursive (with a REC keyword) and (ii) they provide the AND operator to define mutually
recursive value bindings and type declarations. This leads to code like this (taken from <a href="https://learn.microsoft.com/en-us/dotnet/fsharp/language-reference/records">https://learn.microsoft.com/en-us/dotnet/fsharp/language-reference/records</a> )</div>
<div><br>
</div>
<div>
<div><font face="Courier">// Create a Person type and use the Address type that is not defined</font></div>
<div><font face="Courier">type Person =</font></div>
<div><font face="Courier"> { Name: string</font></div>
<div><font face="Courier"> Age: int</font></div>
<div><font face="Courier"> Address: Address }</font></div>
<div><font face="Courier">// Define the Address type which is used in the Person record</font></div>
<div><font face="Courier">and Address =</font></div>
<div><font face="Courier"> { Line1: string</font></div>
<div><font face="Courier"> Line2: string</font></div>
<div><font face="Courier"> PostCode: string</font></div>
<div><font face="Courier"> Occupant: Person }</font></div>
<div><font face="Courier"><br>
</font></div>
<div><font face="Courier">// Create a Person type and use the Address type that is not defined</font></div>
<div><font face="Courier">let rec person =</font></div>
<div><font face="Courier"> {</font></div>
<div><font face="Courier"> Name = "Person name"</font></div>
<div><font face="Courier"> Age = 12</font></div>
<div><font face="Courier"> Address =</font></div>
<div><font face="Courier"> {</font></div>
<div><font face="Courier"> Line1 = "line 1"</font></div>
<div><font face="Courier"> Line2 = "line 2"</font></div>
<div><font face="Courier"> PostCode = "abc123"</font></div>
<div><font face="Courier"> Occupant = person</font></div>
<div><font face="Courier"> }</font></div>
<div><font face="Courier"> }</font></div>
</div>
<div>
<div><br>
</div>
<div>I think this is the sort of thing you are after, right? </div>
<div><br>
</div>
<div>The issue is that this would create **all sorts of problems**, e.g. around DA/DU, initialisation semantics, pattern matching semantics, etc. etc. </div>
<div><br>
</div>
<div>As Ron has suggested - if you want to build a cyclic structure then we already have fantastic technology for that - use classes. You want all the other fields to be immutable? Use final! Once we support patterns in classes, then you’ll get many of the
advantages of using records as a client.</div>
<div><br>
</div>
<div>With records we have carved out a subset of classes that fit the design, for which we can give a great experience without massive changes to the language and its semantics. We could have gone further but we would have to have made compromises that weren’t
worth the price. </div>
<div><br>
</div>
<div>Hope this helps,</div>
<div>Gavin</div>
<div><br>
</div>
<div>PS We also provide another option: Want to be a hacker? Make your record with array components and mutate the array contents to your heart's content!</div>
<div><br>
</div>
<div>
<div><font face="Courier">record Loop(String head, Loop[] tail){};</font></div>
<div><font face="Courier"><br>
</font></div>
<div><font face="Courier">Loop[] tl = new Loop[]{null};</font></div>
<div><font face="Courier"><br>
</font></div>
<div><font face="Courier">var l = new Loop("hello", tl);</font></div>
<div><font face="Courier"><br>
</font></div>
<div><font face="Courier">// A loop of hellos</font></div>
<div><font face="Courier">tl[0]=l;</font></div>
<div><font face="Courier"><br>
</font></div>
<div><font face="Courier">var tmp = l;</font></div>
<div><font face="Courier">for(int i=0; i<100; i++){</font></div>
<div><font face="Courier"> System.out.println(i+": "+tmp.head());</font></div>
<div><font face="Courier"> tmp=tmp.tail()[0];</font></div>
<div><font face="Courier">}</font></div>
<div><font face="Courier"><br>
</font></div>
<div><font face="Courier">// Make l a loop of hello worlds</font></div>
<div><font face="Courier">tl[0]=new Loop("world", new Loop[]{l});</font></div>
<div><font face="Courier"><br>
</font></div>
<div><span style="font-family: Courier;">for(int i=0; i<100; i++){</span></div>
<div><font face="Courier"> System.out.println(i+": "+tmp.head());</font></div>
<div><font face="Courier"> tmp=tmp.tail()[0];</font></div>
<div><font face="Courier">}</font></div>
</div>
<div><br>
</div>
<div>(Don’t tell anyone I showed you this code :-) )</div>
<div><br>
</div>
<div><br>
<blockquote type="cite">
<div>On 30 Jun 2023, at 23:28, David Alayachew <davidalayachew@gmail.com> wrote:</div>
<br class="Apple-interchange-newline">
<div>
<div dir="ltr">
<div style="font-family:monospace" class="gmail_default">Hello all,<br>
<br>
First off, please let me know if I have CC'd the wrong groups. I've CC'd the Amber Dev Team since this involves records, but it's not specifically about records.</div>
<div style="font-family:monospace" class="gmail_default"><br>
</div>
<div style="font-family:monospace" class="gmail_default">---<br>
</div>
<div style="font-family:monospace" class="gmail_default"><br>
</div>
<div style="font-family:monospace" class="gmail_default">For the past couple of weeks, I have been building a program that uses a State Transition Diagram (aka State Machine, Finite Automata, etc. --
<a href="https://en.wikipedia.org/wiki/Finite-state_machine">https://en.wikipedia.org/wiki/Finite-state_machine</a>) to model part of its control flow. I've been using some Amber features to facilitate this (and having a wonderful time of it), but then I hit
a snag.<br>
<br>
Here is a(n EXTREMELY) simplified version of my actual problem. Imagine I have code like the following.<br>
<br>
```java<br>
<br>
sealed interface Node<T> permits StartNode, BranchingNode, EndNode {...unrelated stuff here...}<br>
<br>
record StartNode<T> (Node<T> a, Node<T> b, Node<T> c) implements Node<T> {}<br>
record BranchingNode<T> (Node<T> a, Node<T> b, Node<T> c, ...fields unrelated to transitioning...) implements Node<T> {}<br>
record EndNode<T> (...fields unrelated to transitioning...) implements Node<T> {}<br>
<br>
```<br>
<br>
This type hierarchy is meant to represent a control flow of sorts. Control flow is (imo) best modeled using a State Transition Diagram, so I instinctively reached for that. And since my API needed to be nothing but the data (each Node needed to be tightly coupled
to my internal state representation), I realized that this is an ideal use case for records.<br>
<br>
Things worked out well enough until I tried to model a circular relationship.<br>
<br>
Through chance, all of my control flows up to this point were tree-like, so I could model them by starting from the "leaves," then climbing up until I got to the "roots". To use State Transition Diagram terminology, I started from my exit states and modeled
my way up to my entry states.<br>
<br>
For example, assume that my State Transition Diagram is as so.<br>
<br>
S ---a---> T<br>
S ---b---> U<br>
S ---c---> V<br>
T ---a---> U<br>
T ---b---> V<br>
T ---c---> E<br>
U ---a---> V<br>
U --b|c--> E<br>
V -a|b|c-> E<br>
<br>
S is my StartNode, and E is my ExitNode.<br>
<br>
In this case, modeling with records is easy. It would look like so.<br>
<br>
```java<br>
<br>
ExitNode<UnrelatedStuff> e = new ExitNode<>(...unrelated...);<br>
BranchingNode<UnrelatedStuff> v = new BranchingNode<>(e, e, e, ...unrelated...);<br>
BranchingNode<UnrelatedStuff> u = new BranchingNode<>(v, e, e, ...unrelated...);<br>
BranchingNode<UnrelatedStuff> t = new BranchingNode<>(u, v, e, ...unrelated...);<br>
StartNode<UnrelatedStuff> s = new StartNode<>(t, u, v);<br>
<br>
return s;<br>
<br>
```<br>
<br>
But once I hit a circular reference, I could not figure out how to model the code using the same format.<br>
<br>
For example, what if I say the following instead?<br>
<br>
V ---a---> T<br>
<br>
How do I model that using my current representation?<br>
<br>
Obviously, I could change my representation, but all of them required me to "taint" my representation in incorrect ways.<br>
<br>
For example, I could swap out my records for simple classes where the references to Node's were mutable. But I strongly disapprove of this strategy because these nodes do NOT have a mutable relationship. Obviously, I could put something in the Javadoc, but
I want to fix the incorrect representation, not put a warning sign in front of it.<br>
<br>
Also, I could use indirection, like having a separate Map whose values are the actual Node references and the keys would be a record Pair<T>(String nodeId, Branch branch) {} where Branch is enum Branch { a, b, c, ; } and then give each Node an id, changing
my record to now be record BranchingNode<T> (String id, ...the same as above...) {}. But ignoring the fact that I now have to deal with managing an id, I've also added a lot of unnecessary bloat and indirection just to get the circular reference I wanted.
What should be a direct relationship now requires a Map lookup.<br>
<br>
In that same vein, someone suggested that I use pattern-matching for switch, but that would require me to create a new switch expression for every single state. That's even more verbose and indirect than the Map. At least with the map, I can put them all in
one expression. This strategy has an expression for each state!<br>
<br>
I've been told that there is another pathway involving reflection, but it basically amounts to breaking the rules of Java. Apparently, you can turn off finality to insert in fields you want, and then turn it back on? I liked this idea the least compared to
all of the others, so I didn't pursue it any further.<br>
<br>
In the end, I decided to go down the Map lookup route. But I just wanted to point out my experience with this because it was a surprising and annoying speed bump along an otherwise smooth road. I didn't think that something as small as a circular reference
would require me to uproot my entire solution.<br>
<br>
And finally, I want to emphasize that the same blockers above apply no matter what pathway I go down. I had actually tried implementing this first as an enum before I tried a record, since an enum would more accurately represent my state.<br>
<br>
```java<br>
<br>
enum State<br>
{<br>
<br>
V(T, EXIT, EXIT), //FAILURE -- T cannot be referenced yet<br>
U(V, EXIT, EXIT),<br>
T(U, V, EXIT),<br>
;<br>
<br>
...public final fields and constructor...<br>
<br>
}<br>
<br>
```<br>
<br>
But even then, the same problem occurred -- I can't reference an enum value until it has been declared. I thought going down the path of records would give me the flexibility I wanted, but no dice.<br>
<br>
It reminded me of that one programming meme.<br>
<br>
> * High Quality<br>
> * Quickly Built<br>
> * Low Cost<br>
> <br>
> You can only pick 2<br>
<br>
But instead, it's<br>
<br>
* Circular Relationship<br>
* Immutability<br>
* Direct References<br>
<br>
What are your thoughts? Is this a problem in your eyes too? Or simply a non-issue?<br>
<br>
Thank you for your time and insight!<br>
David Alayachew<br>
</div>
<div style="font-family:monospace" class="gmail_default"></div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</body>
</html>