[m-users.] Does Mercury have a 'reference' type other than thread.mvar ?

[Zoltan Somogyi]

On 2023-07-20 23:39 +02:00 CEST, "Sean Charles (emacstheviking)" <objitsu at gmail.com> wrote:
> Does mercury have anything like a reference type?

The store module in the standard library has some capabilities
that are similar, though they are not identical. But I wouldn't recommend
its use in this case; see below.

> My first attempt was to have a list of UI objects, then render them, that's fine. The object with focus is kept in the world object as a maybe(ui_object), and when I update it, the screen doesn't change because the object I have kept in the maybe record is not the same instance as the one being updated.

My instinct would to give an id to every UI object, and then record
the identity of the UI object that is in focus not using a maybe(ui_object),
but using a maybe(ui_object_id). True, this does mean that you have to do
a lookup to find the ui_object in focus, but if you use a map from ui_object_ids
to ui_objects, this should be more than fast enough.

The point is that it would make the copy of each ui_object in the ui_object_id
to ui_object map the authorative (master) copy of that ui_object.
Updating this copy would be the philosphical equivalent of a commit
in a database transaction, since this map would be the source of all
screen updates. A given ui_object could have copies elsewhere, but
they would not be authorative copies. It also means that code that
updates an ui_object in this map would also need to know where all its
other copies are, and update them as well. For example, you could
record the ui_object in focus as maybe(pair(ui_object_id, ui_object)).
The second half of this pair would be a slave copy, updated whenever the
master copy is updated.

>                 !:W = !.W ^w_focus := yes(Out)

Note that "!W ^ w_focus := yes(Out)" is a shorter equivalent of the line above.
 
> Presumably I now have to find a scheme whereby I can iterate a tree of objects, and then update the one with event focus

Why would you need to do that? Is there are any reason why

- look up the object with focus by its id in the map,
- update that object,
- put the updated object back into the map
- update all of its copies elsewhere

wouldn't work?

> but there other problems to solve to like finding out which component is uder a mouse down event etc.

I am not an UI designer, but my first thought would be that it would mean that each
ui object, or its id, would also need to be in some form of k-d tree. That would change
the above scheme only slightly.

> I have a suspicion that my long time owned and once read copy of Purely Functional Data Structures (Okasaki) might be useful?

In the long term, possibly yes. However, I would certainly recommend
that you use the simplest possible data structures to begin with,
and explore the use of more complex, if faster, structures only after
the basic logic has been debugged.

Zoltan.