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

[Sean Charles (emacstheviking)]

Thanks Zoltan.

I have already been reading up on the other modules that are available. I am going to use bitmap or various flags as it says it's particularly efficient it says for 'eight bit bytes'. digraph might also be useful for maybe implementing a topological sort if needed. I've already got drag and drop of files into the window, and parsing those files....some of which depend on others etc.

I came to the same conclusion about using a map too! I've used maps in my transpiler and I find the Mercury syntax for them quite pleasing to use.

I don't think there will be multiple copies of objects, the map would be the definitive collection of objects; I would have a map of objects that would be the master copies, and then other structures would merely be collections of those ids in whatever shape is necessary. So, the map is the pool of state, the trees of ids would change as the, for example, the z-ordering or parenting of things was changed etc.

As for keeping it simple to start with, yes. I am a huge believer in getting something that works first and foremost, once you have something that works, then you can start to pick at it and see if it can be improved if it needs improvement.

The map updates etc might be important.  I plan to build a framework that allows for animations on *anything* so that tweening of multiple attributes can be applied as well; this might well be the first editor that has a particle system in it! :D   I was gong to use Godot for the IDE, but tbh, I can't imagine not using Mercury, as Volker and I have both said, the feeling of solidity and correctness it gives regarding the final executable is not something easily obtained with other languages really.

Thank you again.
Sean



> On 20 Jul 2023, at 23:25, Zoltan Somogyi <zoltan.somogyi at runbox.com> wrote:
> 
> 
> 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.