[External] : Re: Question about circular references

[Holo The Sage Wolf]

While I can't comment about Frontend, and the paths finding case is clearly
correct, but from my experience in NLP, having a "frozen repository" of
lookup map is more convenient.

Specifically, the ability to copy the repository in an efficient way (as it
is just a fixed number of maps) is very useful for hot-commits ("frozen
repo" is active, while there is a non-frozen repo in the background,
changing all the time, every X amount of time/changes I copy the non-frozen
repo into a frozen repo and replace the old active with the new frozen repo)

You can also do it using cyclic GADT but I don't see how you both enable
fast copying and fast freezing. You can also sidestep these problems adding
util method to add nodes/edges (as in, create new graph with the extra
nodes/edges), but this becomes very hard to reason without a reference to
every node (or without identifiers, the Poor's-man-ref), in which case you
basically have a backing repository with "get frozen copy" method that
return your GADT

On Tue, Jul 4, 2023, 22:06 David Alayachew <davidalayachew at gmail.com> wrote:

> Hello Ron,
>
> Thank you for your response!
>
> I have to run for holiday festivities, so this will be my last response
> for several hours. I'll address any future points tomorrow when I get back.
>
> > Cyclic is in fact possible
>
> Since I conceded that cyclic is in fact possible (regardless of the
> trouble I have to go through to get it), there's not much I have to say
> other than that you are correct, cyclic is in fact possible.
>
> > BIG problem
>
> I spend a lot of my time writing front end code, path finding algorithms,
> and natural language processing. These are basically the 3 realms I spend
> 90% of my time in. All 3 of these treat State Transition Diagrams as the
> holy grail for representing control flow and decision making. Literally ALL
> of the business logic I write for these initiatives involves me emulating a
> state transition diagram directly into Java code.
>
> For front end code, after I click a button, knowing what the next buttons
> should be activated or deactivated is an ideal use case for a state
> transition diagram. If I write a calculator, pressing the start button
> should activate the number buttons and the operator buttons, but not the
> negation button or the clear buttons. By using a state transition diagrams,
> you clearly define all possible path in control flow execution, which is
> GOLDEN for eliminating bugs in front end code.
>
> For path finding algorithms, I don't think that requires any explanation
> lol. State transition diagrams were literally built for path finding
> algorithms lol. You need a very good reason to NOT use a state transition
> diagram.
>
> And for natural language processing, you follow almost the exact same
> logic as the front end code example above. By entering a word, you have
> filtered the domain of possible follow up words considerably, depending on
> the type of the word. It is this control flow wrangling that allows
> something as prohibitively expansive as the English language to be
> effectively wrangled down to Earth with State Transition Diagrams and
> Pattern matching. It's no secret that the first thing I ever used Amber for
> was natural language processing ()
>
> All of that is to say this. This is a problem that I pay a tax for several
> times a day, every day. So in my eyes, this is a very large thorn in my
> side.
> I treat it similarly to how we treated enums. Sure, they were
> representable as static final fields, but introducing them as an enum
> opened up an entire world of possibilities that I could use them for. Enums
> are my literal favorite feature in all of Java because, like
> pattern-matching and state transition diagrams, it allows you to be able to
> wrestle a prohibitively complex domain (serialization and deserialization
> of a small set of values) into an ergonomic feature that's easy to wield.
>
> I'll respond to any further questions when I get back.
>
> Thank you for your time and help!
> David Alayachew
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20230706/a51f93f6/attachment.htm>